SEO 개선을 위해 NGINX Plus 사용하기

NGINX와 NGINX Plus 를 사용하면 SEO 불이익을 받지 않고 필요에 따라 사이트 아키텍처를 변경할 수 있습니다. NGINX의 고성능과 구현하기 쉬운 rewrite 규칙을 통해 기존 URL을 새 페이지 위치로 쉽게 리다이렉션할 수 있습니다. 또한 강력한 rewrite 규칙 및 기타 NGINX 기능을 사용하면 HTTPS로 쉽게 전환할 수 있으므로 사이트에 대한 사용자 신뢰도가 높아지고 SEO가 향상됩니다.

목차

1. 문제
2. SEO 개선 파트 1 – rewrite 규칙
3. SEO 개선 파트 2 – SSL/TLS 및 HTTP/2
4. 기대할 수 있는 사항

1. 문제

SEO 순위 향상

검색 엔진 최적화(SEO)는 모든 사이트의 관심사입니다. 이 블로그 포스트의 교훈은 사이트를 관리하는 모든 사람에게 어느 정도 적용됩니다. 하지만 SEO는 크고 작은 이커머스 사이트에 있어 “죽느냐 사느냐”의 문제입니다.

관련 제품에 대한 Google 검색 결과의 첫 페이지, 가급적이면 상단에 표시되는 것은 Amazon이나 eBay와 같은 “순수” 이커머스 사이트와 Macy’s나 Nordstrom과 같이 웹사이트를 운영하는 유명 오프라인 리테일러를 포함한 모든 온라인 리테일러에게 매우 중요한 일입니다. “스크롤 후 표시”는 매출, 경쟁력 및 브랜드 인지도에 손상을 줍니다. 또한 SEO의 성공은 스스로 강화되기 때문에 잘못된 SEO로 인한 피해는 영구적이며 심지어 치명적일 수도 있습니다.

안타깝게도 웹사이트의 운영상 요구 사항이 좋은 SEO 결과를 저해할 수 있습니다. 리테일러는 종종 한 번에 수백 개 또는 수천 개씩 제품의 URL을 변경해야 하는 경우가 많습니다. URL을 변경하는 일반적인 이유는 제품 카테고리를 추가 또는 변경하거나 콘텐츠 배포 네트워크(CDN)를 추가하는 등 콘텐츠 저장 및 전송을 위한 아키텍처를 개선하기 위해서입니다.

또한 특정 제품 페이지 또는 소규모 제품 그룹에 대한 변경도 자주 발생합니다. 제품이 새 카테고리로 이동하거나 다른 카테고리에 추가되거나 유사한 제품으로 대체될 수 있습니다.

이러한 변경 사항은 SEO 및 검색 엔진 결과를 손상시킬 수 있습니다. 어떻게 이런 일이 발생할까요? 그 이유는 모든 검색 엔진의 기본 기능에 내장되어 있기 때문입니다:

  • 검색 엔진은 웹을 크롤링하고 대부분의 페이지에 대한 정보를 기록합니다(index).
  • 각 페이지에는 주요 용어 사용 및 사용자 검색과의 관련성, 각 용어와 관련된 링크 수, 링크 페이지의 인기도 및 기타 요인에 따라 가중치가 부여됩니다.
  • 검색 엔진은 웹 크롤링을 반복합니다:
    • 검색 엔진이 저장된 URL에서 페이지를 찾으면 검색 엔진은 페이지의 항목을 새 정보로 업데이트합니다. 순위 신호가 변경되면 페이지의 순위가 상승하거나 하락합니다.
    • 리다이렉션 없이 페이지를 이동하면 검색 엔진은 404 에러를 수신합니다. 이전 검색 엔진 순위(예: Google PageRank)는 재배치된 페이지로 이전되지 않습니다. 대신 재배치된 페이지의 SEO 기록이 처음부터 다시 시작됩니다.

이 프로세스를 검토하면 일상적인 사이트 유지 관리 및 사이트 구조 변경으로 인해 발생하는 근본적인 문제를 발견할 수 있습니다. 이러한 사이트 계층 구조의 변경으로 인해 페이지가 동일하더라도 특정 페이지의 URL이 변경됩니다. 검색 엔진이 다음 크롤링에서 사이트를 찾지 못하면 검색 결과에서 페이지의 순위가 급락합니다.

NGINX는 이러한 유형의 사이트 변경으로 인해 발생한 비즈니스 문제와 유사한 변경을 지속적으로 필요한 기업 고객을 지원했습니다. 이 회사의 제품 페이지에 대한 SEO 등급이 급격히 떨어지고 있었습니다. 검색 결과의 악화와 함께 매출도 즉시 감소했습니다.

이 고객을 위해 NGINX가 구현한 솔루션은 사이트 아키텍처를 변경해야 하는 모든 사이트에 도움이 되는 동시에 우수한 SEO 결과를 지속적으로 달성할 수 있습니다.

2. SEO 개선 파트 1 – 규칙 rewrite

NGINX와 NGINX Plus 는 요청 리다이렉션을 위한 강력하고 유연한 도구입니다. 이 접근 방식에서는 NGINX rewrite 규칙을 사용하여 사이트의 이전 계층 구조가 있을 때 설정된 이전 URL을 새 계층 구조와 일치하는 새 URL로 리다이렉션합니다.

NGINX 및 NGINX Plus 의 강력한 rewrite 기능은 다음과 같은 다양한 SEO 문제에서 성공적인 것으로 입증되었습니다:

  • 사용자 친화적인 가시적 URL
  • 이전 형식의 URL을 새로운 형식의 URL로 변환하기
  • 사이트 이름에 www. 접두사 사용 및 비사용 표준화
  • URL 요소, 특히 도메인 네임의 일반적인 철자 오류 수용

최근 NGINX에 도움을 요청한 대형 이커머스 사이트는 사이트 계층 구조를 변경한 후 기존 링크와 SEO 결과가 “깨졌습니다”. 이 사이트는 rewrite 규칙, 캐스케이딩 구성 파일, 사용자 지정 애플리케이션 코드를 혼합하여 URL을 rewrite하고 있었습니다. 하지만 기존 솔루션은 인바운드 링크와 검색 엔진 쿼리를 새 URL로 안정적으로 전송하지 못했습니다. SEO 결과가 지속적으로 악화되고 매출이 감소하는 것을 목격했습니다.

NGINX rewrite 규칙을 통해 기존 인바운드 링크와 검색 엔진 쿼리를 안정적으로 지원할 수 있을 뿐만 아니라 기존 검색 엔진 정보를 새 사이트 구조에 매핑할 수 있었습니다. 조건부 rewrite 규칙을 사용하여 이전 스타일의 링크는 rewrite하고 최신 링크는 변경하지 않습니다.

다음은 NGINX 구성 코드를 사용하여 SEO 결과를 유지하면서 한 도메인 네임에서 다른 도메인 네임으로 콘텐츠 전송을 지원하는 예제입니다. 다음 코드는 클라이언트를 완전히 다른 도메인 네임으로 리다이렉션합니다.

server {
    listen 80;
    server_name www.old-name.com;
    return 301 $scheme://www.new-name.com$request_uri;
}

이 예에서는 다음과 같습니다.

  • listen 지시문은 포트 80에서 HTTP 트래픽을 캡처합니다.
  • server_name 지시문은 이전 도메인 네임을 가진 URL에 변경 사항을 적용합니다.
  • return 지시문은 이전 URL을 새 도메인 네임으로 매핑합니다.

자세한 예제와 함께 rewrite 및 try_files 지시문을 사용을 포함한 이 접근 방식에 대한 자세한 내용은 블로그에서 NGINX rewrite 규칙 만들기를 참조하세요.

스택에 NGINX를 추가하려면 여러 가지 성능 최적화 전략을 사용할 수 있습니다. NGINX rewrite 규칙을 사용하면 SEO 패널티에 대한 걱정 없이 사이트 아키텍처를 변경할 수 있습니다. 기존 애플리케이션 서버 앞의 리버스 프록시 서버로 NGINX를 사용하여 애플리케이션 서버에서 생성된 정적 콘텐츠(예: 이미지 파일 및 CSS 코드)와 동적 콘텐츠를 모두 캐시하고 HTTPS와 같은 프로토콜을 종료하여 애플리케이션 서버의 작업을 더욱 많이 offload 할 수 있습니다.

3. SEO 개선 파트 2 – SSL/TLS 및 HTTP/2

사용자와 웹사이트 간의 통신을 위해 SSL/TLS 암호화를 구현하는 등 아직 HTTPS를 사용하지 않는 경우, rewrite 규칙을 구현하면 HTTPS로 전환하여 SEO 결과를 개선할 수 있습니다. rewrite 규칙을 사용하면 사이트의 http:// 버전에 대한 요청이 새로운 https:// 위치로 리다이렉션되어 인바운드 링크의 효과나 SO 성능이 손실되지 않도록 할 수 있습니다.

특히 민감한 사용자 데이터가 없는 페이지의 경우에도 지금이 HTTPS로 전환하기에 특히 좋은 시기입니다. 그 이유는 다음과 같습니다:

  • 검색 엔진은 점점 더 HTTPS 사용에 대한 보상을 강화하고 있으며, 이는 상대적으로 HTTP에 불이익을 주고 있다는 의미입니다.
  • Chrome 브라우저는 HTTPS를 사용하지 않는 웹사이트의 URL 표시줄에 해당 사이트가 안전하지 않다는 것을 의미하는 아이콘(빨간색 “X”가 표시된 자물쇠를 추가했습니다.
  • 작년에 상위 백만 개 사이트 중 HTTPS를 사용하는 사이트가 거의 두 배로 늘어나는 등 HTTPS 사용이 증가하고 있으며, 이를 사용하지 않는 사이트는 사용자에게 좋지 않은 방식으로 눈에 띄게 될 수 있습니다.
  • HTTP/2가 도입되면서 SSL/TLS 및 HTTP/1.x 사용과 관련된 성능 저하를 거의 모두 또는 대부분 피할 수 있게 되었습니다.
  • 리버스 프록시 서버로 NGINX를 사용하면 리버스 프록시 서버에서 HTTPS를 종료하고 백엔드 서버와의 통신은 성능 오버헤드 없이 HTTP를 사용합니다.
  • 서버 간 보안 통신을 원하는 경우, 마이크로서비스와 NGINX 마이크로서비스 참조 아키텍처의 Fabric Model을 사용하면 성능 저하 없이 서비스 간 통신에 SSL/TLS를 사용할 수 있습니다.
SEO 결과를 개선하기 위한 전반적인 전략의 일환으로 NGINX Plus가 클라이언트의 HTTP/2 연결을 종료하고 로컬 백엔드 서버에 대한 암호화되지 않은 연결을 사용하는 방법을 그래픽으로 보여줍니다.

세션 캐싱, 세션 티켓, OCSP 스테이플링(NGINX 서버의 SSL/TLS 응답에 SSL/TLS 인증서 콘텐츠 포함) 등의 기술을 사용하여 성능 저하를 최소화하는 방식으로 HTTPS를 구현할 수 있습니다.

이전 섹션에서 설명한 대로 rewrite 규칙을 사용하면 SEO 또는 인바운드 링크 효과의 저하 없이 SSL/TLS 및 HTTP/2를 채택할 수 있습니다. 예를 들어 캐싱 지원, SSL/TLS termination 및 /또는 HTTP/2 termination를 포함하는 리버스 프록시 서버를 구현하는 경우 rewrite 규칙을 사용하면 일부 또는 모든 파일에 대한 새로운 물리적 레이아웃에 대해 이전 URL 구조를 지원할 수 있습니다.

4. 기대할 수 있는 사항

앞서 언급한 고객은 NGINX를 신속하게 구현하여 뛰어난 결과를 얻었습니다. rewrite 규칙을 사용하여 이전 URL 구조를 새로운 사이트 계층 구조에 매핑하여 제품의 이전 SEO 순위를 빠르게 회복하고 수익이 빠르게 반등했습니다. 이 고객은 여전히 HTTPS를 완전히 구현할 수 있는 기회가 있으며, 이를 통해 SEO 순위를 더욱 높일 수 있습니다.

NGINX rewrite 규칙을 사용하면 사이트 계층 구조나 URL 콘텐츠 변경으로 인한 SEO 불이익 없이 필요한 사이트 관리 유연성을 확보하고, 성능 최적화 전략을 구현하고, HTTPS로 전환할 수 있습니다.

NGINX Plus 를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.