웹사이트 SEO 설정에서 어떤 오류가 페이지 색인에 영향을 미칠까요?

페이지가 검색 엔진에 색인되지 않았다고 해서 반드시 키워드 설정이 잘못된 것은 아닙니다. 더 직접적인 원인은 검색 엔진이 페이지에 접근할 수 없거나, 페이지에 색인 금지 표시가 되어 있거나, 표준 URL이 다른 페이지를 가리키는 것일 수 있습니다. 설정이 모두 정상인 페이지도 콘텐츠 중복이나 가치 부족 등의 이유로 아직 색인되지 않았을 수 있습니다.

문제를 점검할 때는 먼저 ‘크롤링할 수 없음’, ‘색인하지 말라는 지시가 있음’, ‘크롤링했지만 색인되지 않음’을 구분해야 합니다. 페이지가 검색되지 않는다고 해서 제목을 반복해서 수정하거나 URL을 제출하지 마세요. 예를 들어 Google에서는 Search Console의 ‘URL 검사’에서 페이지 상태를 확인한 다음, 구체적인 원인에 따라 조치할 수 있습니다.

페이지가 실제로 색인되지 않았는지 먼저 확인하기

Search Console에 프로토콜, 도메인, 경로, 마지막 슬래시를 포함한 전체 URL을 입력하세요. 검사 결과에는 해당 URL이 Google 색인에 포함되어 있는지와 크롤링, 색인 생성, 표준 페이지에 관한 정보가 표시됩니다. 사이트에 매개변수가 있는 주소와 없는 주소, 슬래시가 있는 주소와 없는 주소가 모두 존재한다면 실제로 검색 결과에 표시하려는 버전을 반드시 확인하세요.

‘URL이 Google 색인에 포함되어 있음’은 어떤 키워드로 검색해도 페이지를 찾을 수 있다는 뜻이 아닙니다. 색인 생성과 순위는 별개의 문제입니다. 반대로 site: 검색으로 페이지를 찾지 못하더라도, 그것만으로 색인되지 않았다고 확정할 수는 없습니다. 구체적인 상태는 URL 검사 결과를 함께 확인해야 합니다.

URL 검사의 색인 상태는 Google이 파악한 정보를 반영합니다. 실시간 테스트에서는 현재 페이지에 접근할 수 있는지와 페이지 설정을 확인할 수 있지만, 실시간 테스트를 통과해도 페이지 색인이 보장되는 것은 아닙니다. 설정을 변경한 후에는 검색 엔진이 페이지를 다시 크롤링하고 처리할 때까지 기다려야 합니다.

페이지에 접근할 수 있는지 확인하기: 크롤링 제한 및 서버 응답 점검

robots.txt의 잘못된 차단은 사이트를 공개할 때 우선적으로 점검해야 하는 문제입니다. 예를 들어 테스트 단계에서 Disallow: /를 설정한 뒤 사이트 공개 후에도 삭제하지 않으면, 해당 규칙의 영향을 받는 크롤러가 사이트 경로에 접근할 수 없습니다. 도메인 루트 디렉터리의 /robots.txt를 확인하고, 규칙이 어떤 크롤러와 경로에 적용되는지 살펴본 다음 불필요한 제한을 삭제하거나 수정하세요.

robots.txt는 크롤링을 제어하는 파일이지, 색인을 확실하게 금지하는 방법은 아닙니다. 차단된 URL도 다른 페이지의 링크를 통해 검색 결과에 표시될 수 있지만, 검색 엔진은 해당 콘텐츠를 읽을 수 없습니다. 공개 페이지의 색인을 원하지 않는다면 크롤링을 허용하고 유효한 noindex 지시어를 사용하세요. 콘텐츠를 비공개로 유지하려면 SEO 지시어에 의존하지 말고 로그인 인증과 같은 접근 제어를 적용해야 합니다.

페이지가 반환하는 HTTP 상태 코드도 처리 결과에 영향을 줍니다. 공개 페이지는 안정적으로 200 상태 코드를 반환해야 합니다. 404와 410은 페이지가 없거나 삭제되었음을 나타내고, 5xx는 서버, 호스팅 서비스 또는 보안 설정을 점검해야 한다는 뜻입니다. 사이트에 지역 제한, CAPTCHA 또는 방화벽 규칙이 있다면 이러한 설정이 검색 엔진의 크롤링을 차단하지 않는지 확인하세요. 자신의 브라우저에서 페이지가 정상적으로 보이는지만 확인해서는 안 됩니다.

놓치기 쉬운 또 다른 문제는 ‘소프트 404’입니다. 서버는 200을 반환하지만 페이지에는 제품이 없다는 메시지, 빈 콘텐츠 또는 오류 안내가 표시되는 경우입니다. 삭제되었으며 대체 콘텐츠가 없는 페이지는 적절한 페이지 없음 상태 코드를 반환해야 합니다. 명확한 대체 페이지가 있을 때만 합리적인 리디렉션을 고려하고, 관련 없는 오래된 URL을 모두 홈페이지로 리디렉션하지 마세요.

접근은 가능하지만 ‘색인하지 않음’으로 설정된 경우

페이지 소스 코드의 <meta name="robots" content="noindex"> 또는 HTTP 응답 헤더의 X-Robots-Tag: noindex는 검색 엔진에 색인하지 말라는 지시를 전달합니다. 테스트 사이트를 정식 도메인으로 이전한 후에도 사이트 제작 시스템의 ‘검색 엔진 색인 금지’ 설정, 페이지별 SEO 설정 또는 서버 응답 헤더에 이 설정이 남아 있을 수 있습니다.

점검할 때 관리자 페이지의 설정만 확인하지 마세요. 페이지 소스 코드를 열어 noindex를 검색하고, 응답 헤더도 함께 확인해야 합니다. PDF와 같은 HTML이 아닌 파일은 특히 응답 헤더의 지시를 확인하세요. 페이지를 공개하고 색인하려면 해당 제한을 제거하고, robots.txt가 검색 엔진의 재크롤링을 차단하지 않도록 해야 합니다. 그렇지 않으면 지시가 변경된 사실을 검색 엔진이 제때 확인하지 못할 수 있습니다.

사이트 전체의 모든 noindex를 삭제할 필요는 없습니다. 검색 결과 페이지, 중복 필터 페이지 또는 독립적인 검색 가치가 없는 다른 페이지는 실제로 색인할 필요가 없을 수 있습니다. 중요한 것은 제품 상세 페이지, 카테고리 페이지 또는 자연 검색을 통한 방문이 필요한 다른 페이지에 제한이 잘못 적용되었는지 확인하는 것입니다.

표준 URL과 리디렉션 설정이 잘못된 경우

표준 URL 태그 rel="canonical"는 검색 엔진에 어떤 버전을 우선 선택해야 하는지 알려줍니다. 모든 제품 페이지가 실수로 홈페이지나 동일한 카테고리 페이지를 표준 URL로 지정하면, 검색 엔진은 각 제품 페이지를 별도로 색인하지 않고 중복 버전으로 판단할 수 있습니다.

페이지 소스 코드나 응답 헤더에서 canonical을 확인하고, 해당 URL이 접근 가능하며 페이지 콘텐츠와 일치하고 색인하려는 주소인지 확인하세요. 독립적인 콘텐츠가 있는 페이지는 자신을 표준 URL로 지정하는 것이 일반적인 방법입니다. 콘텐츠가 거의 동일한 매개변수 페이지는 실제 필요에 따라 주요 버전을 가리키도록 설정할 수 있습니다. canonical은 지시가 아닌 참고 신호이므로, Google은 페이지 콘텐츠, 링크, 리디렉션 등의 신호를 바탕으로 다른 표준 URL을 선택할 수도 있습니다.

리디렉션도 확인해야 합니다. HTTP와 HTTPS, 이전 도메인과 새 도메인, 경로 변경 사이에 최종 목적지가 명확해야 합니다. 리디렉션 루프가 발생하거나 관련 없는 페이지로 이동하거나, 사이트맵과 사이트 내부 링크가 계속 이전 주소를 가리키지 않도록 하세요. URL 검사에서 Google이 다른 표준 페이지를 선택한 것으로 표시되면 원래 URL을 반복해서 제출하는 대신 두 페이지의 콘텐츠와 신호를 비교해야 합니다.

다국어 사이트에서는 언어별 페이지를 실수로 모두 영어 홈페이지의 표준 URL로 지정하는 경우도 많습니다. 언어나 지역별 페이지가 각각 유의미한 콘텐츠를 제공한다면 각 페이지의 canonical과 hreflang 표기를 확인하세요. hreflang은 언어와 지역 간의 대응 관계를 나타내는 용도이며, 크롤링과 색인이 가능한 페이지 설정을 대체하지 않고 특정 지역에 지정한 버전이 반드시 표시되도록 보장하지도 않습니다.

페이지를 색인할 수 있지만 검색 엔진이 페이지를 찾거나 이해하기 어려운 경우

고립 페이지에는 크롤링할 수 있는 사이트 내부 진입 경로가 없습니다. 제품 상세 페이지에 사이트 내부 검색이나 양식 제출 또는 복잡한 상호작용을 통해서만 접근할 수 있다면 검색 엔진이 해당 페이지를 찾기 어려울 수 있습니다. 관련 카테고리 페이지, 내비게이션 또는 콘텐츠 페이지에서 일반 HTML 링크를 제공하고, 유효한 href가 있는 <a> 요소로 대상 페이지를 연결하세요.

XML 사이트맵은 검색 엔진이 발견하기를 원하는 URL을 제공하는 데 도움이 되지만, 사이트맵 제출이 색인 요청을 의미하는 것은 아닙니다. 파일에는 정상 상태 코드를 반환하고, 색인이 허용되며, 표준 버전으로 지정하려는 URL을 우선적으로 포함해야 합니다. 리디렉션, 404 또는 noindex 페이지를 대량으로 포함하면 문제를 파악하기 어려워집니다. 제출 후에는 Search Console에서 사이트맵이 정상적으로 처리되었는지와 관련 페이지의 상태를 확인할 수 있습니다.

JavaScript로 주요 콘텐츠를 표시하는 사이트는 검색 엔진이 핵심 콘텐츠를 가져와 렌더링할 수 있는지도 확인해야 합니다. 초기 HTML이 거의 비어 있고 스크립트, API 또는 리소스가 차단되어 있다면 검색 엔진이 보는 콘텐츠는 브라우저에 표시되는 내용과 다를 수 있습니다. URL 검사의 실시간 테스트를 이용해 렌더링된 페이지와 리소스 로딩 상태를 확인하고, 필요한 경우 렌더링 방식을 변경하거나 관련 리소스에 대한 접근을 허용하세요.

‘크롤링됨 - 현재 색인이 생성되지 않음’이 반드시 기술적인 오류를 뜻하는 것은 아닙니다. 여러 제품 페이지가 모델명만 다르고 본문, 이미지, 설명이 거의 동일하다면 검색 엔진이 각 페이지를 모두 색인하지 않을 수 있습니다. 제품의 실제 차이를 반영해 사양, 사용 조건 또는 기타 유용한 정보를 추가하세요. 독립적인 가치가 없는 중복 페이지는 통합하거나 표준 버전을 명확히 지정하는 방법을 고려할 수 있습니다. 키워드 추가나 제목 수정만으로는 페이지 자체의 콘텐츠 가치를 대신할 수 없습니다.

수정 후 확인 방법

매번 한 가지 명확한 문제를 우선적으로 해결하세요. 예를 들어 잘못 추가된 noindex를 제거하거나, canonical을 수정하거나, 차단된 경로에 대한 접근을 복구할 수 있습니다. 변경 사항을 게시한 후에는 실제 URL의 상태 코드, 페이지 소스 코드, 응답 헤더를 다시 확인하고 Search Console의 실시간 테스트를 통해 검색 엔진이 변경 사항을 확인할 수 있는지 점검하세요.

중요한 페이지는 검사 후 색인 생성을 요청할 수 있습니다. 여러 페이지에 영향을 미치는 문제는 개별 페이지를 하나씩 제출하기 전에 템플릿, 사이트 설정 또는 서버 규칙을 먼저 수정해 근본 원인을 해결해야 합니다. 색인 요청과 사이트맵 제출은 색인 생성이나 처리 시간을 보장하지 않습니다. 상태가 오랫동안 바뀌지 않는다면 계속해서 반복 제출하는 대신 실제 크롤링 결과, 표준 URL 및 페이지 콘텐츠를 다시 확인하세요.