의도한 페이지와 재사용 가능한 증거로 시작하세요
검색자에게 노출되길 원하는 공개 페이지를 목록화하세요: 주요 상품, 기사, 카테고리, 이전된 URL 등. 각 항목에 대해 선호 URL, 예상 응답, 색인 가능성, 템플릿, 책임자, 우선순위를 기록하세요. 합법적 제외 목록은 따로 유지합니다.
대표 URL에 대해 비인증(로그인 없는) 응답, 헤더, 리디렉션 경로, 페이지 소스, 렌더된 뷰, 내부 링크 상태 및 사이트맵 상태를 캡처하세요. 모든 템플릿과 URL 패턴을 샘플링하세요. 증거는 날짜가 중요합니다: CDN 설정, 배포, 동의(컨센트) 레이어, 개인화 등은 이후에 변경될 수 있습니다.
홈페이지가 통과한다고 해서 목록 페이지, 상품 변형, 지역화된 경로가 모두 정상이라는 보장은 없습니다.
수정 및 이후 회귀를 비교할 수 있도록 날짜가 있는 헤더와 렌더 증거를 보관하세요.
색인 가능성(indexability)을 명확한 결정으로 만드세요
색인 가능성은 페이지가 검색 인덱스에 포함될 수 있음을 의미하며, 크롤링이나 순위와 동일하지 않습니다. HTML의 meta robots 지시문과 X-Robots-Tag 응답 헤더를 확인하세요. noindex 지시는 검색엔진에 페이지를 노출하지 말라고 말합니다; X-Robots-Tag는 PDF 같은 비-HTML 파일에도 적용됩니다.
robots.txt는 별도로 검토하세요. 크롤러는 noindex 지시문을 발견하려면 페이지에 접근해야 하므로 해당 URL을 차단하면 지시문을 보지 못할 수 있습니다. 배포된 공개 응답을 확인하세요. CMS 설정이나 환경 플래그가 규칙을 추가할 수 있습니다. noindex는 접근 제어가 아닙니다: 민감한 자료는 인증과 적절한 보안 검토로 보호하세요.
의도된 색인 페이지에서 noindex, 로그인 응답, 스테이징 참조, 필수 자산의 차단을 표시하세요.
HTML head가 없더라도 HTTP 응답 헤더에 지시문이 있을 수 있습니다.
하나의 선호 URL을 일관되게 유지하세요
정규화(canonicalization)는 HTTP/HTTPS, 호스트, 추적 파라미터, 필터, 인쇄용 페이지 등 중복되거나 매우 유사한 버전들 중 선호 URL을 식별합니다. canonical 요소, 내부 링크, 사이트맵 URL, 리디렉션 목적지를 비교하세요. 색인 가능한 페이지의 경우 보통 동일한 절대 선호 URL을 가리켜야 합니다.
중복을 퇴역시킬 때는 서버 측 영구 리디렉션을 사용하세요. Google은 영구 리디렉트와 rel=canonical을 강력한 신호로 설명하며, 사이트맵 포함은 약한 신호입니다; 신호를 일치시키면 우선순위가 강화됩니다. robots.txt로 정규화를 시도하거나 서로 경쟁하는 canonical을 주지 마세요. 자기 자신을 참조하는(rel=self) canonical은 선호 버전을 명시하는 데 도움이 되지만 검색 엔진의 최종 선택은 통제 범위를 벗어납니다.
변형들, 선호 대상, 필요한 제어 방식, 책임자를 문서화하세요.
마이그레이션 전 구(舊)-신(新) 매핑을 테스트하고 되돌릴 수 있는 리디렉션 변경을 준비하세요.
상태 코드와 리디렉션 동작을 확인하세요
상태 코드는 브라우저와 크롤러에 무슨 일이 있었는지를 알려줍니다. 중요한 라이브 페이지는 의도한 콘텐츠와 함께 의미 있는 2xx 응답을 반환해야 합니다. 대체할 관련 항목이 없는 페이지는 진짜 404 또는 410을 반환해야 하고, 이동된 콘텐츠는 가장 적절한 대체로 도달해야 합니다. 오류만 보여주는 200 페이지는 소프트 404로 처리될 수 있습니다.
모든 리디렉션 홉을 기록하세요. Google은 일반 웹 크롤링에서 최대 10 홉까지 따르는 경향이 있지만, 체인은 지연과 취약성을 더합니다. Google은 5xx 및 429 응답이 크롤링을 일시적으로 늦출 수 있고, 지속적인 서버 오류는 궁극적으로 인덱스에서 URL을 제거할 수 있다고 명시합니다. 반복적 실패는 애플리케이션, CDN, 오리진, 캐시, 의존성, 배포 레이어 전반의 엔지니어링 소유자와 함께 조사하세요.
원본 URL, 홉, 코드, 최종 URL 및 예상 상태를 저장하세요.
또 다른 홉을 추가하기보다 중복된 CMS, CDN, 호스트, 로케일 또는 슬래시 규칙을 제거하세요.
자바스크립트 렌더링과 라우트를 검증하세요
핵심 템플릿에 대해 초기 HTML과 렌더된 뷰 둘 다를 검사하세요. 렌더 후 주요 콘텐츠, 헤딩, 링크, canonical, robots 지시문 및 상태가 존재하는지 확인하세요. Google은 크롤, 렌더, 인덱스의 별도 단계를 설명하며 렌더된 HTML에서 보이지 않는 콘텐츠는 색인될 수 없다고 말합니다.
네비게이션에는 href 값이 있는 앵커 요소를 사용하세요. 프래그먼트만으로 동작하는 라우트는 별도 콘텐츠 로드 시 디스커버리에 신뢰할 수 없습니다. 존재하지 않는 상품, 기사, 필터링된 URL을 직접 요청해 보세요. 클라이언트 측 애플리케이션은 실제 오류 상태가 필요합니다; Google은 서버 404로 라우팅하거나 noindex를 추가해 소프트 404를 피할 것을 문서화합니다. 서버 렌더링 또는 프리렌더링이 도움이 될 수 있지만 배포된 응답을 검증하세요.
응답 HTML, 렌더된 HTML, 사람 브라우저 뷰에서 의미 있는 차이를 확인하세요.
원본 HTML을 우선시하세요; JavaScript가 설정한다면 비충돌성의 단일 canonical을 보장하세요.
사이트맵과 내부 링크를 깨끗하게 유지하세요
사이트맵은 발견의 지도일 뿐 색인 명령이 아닙니다. 성공적이고 의도된 선호 canonical URL만 포함하세요; 리디렉션, 오류, noindex 페이지, 파라미터 중복, 보호된 URL은 제외하세요. Google은 절대 경로의 완전한 URL을 권장하며 사이트맵 포함을 정식 canonical 신호가 아닌 힌트로 처리합니다.
사이트맵을 검증하고 의도된 색인 목록 및 네비게이션과 비교하세요. Google은 UTF-8 인코딩과 압축하지 않은 경우 50MB 또는 50,000 URL의 제한을 문서화합니다. 큰 사이트는 유용한 그룹으로 분할하고 인덱스 사이트맵을 사용하세요. lastmod는 유의미하고 검증 가능한 페이지 변경에 대해서만 갱신하세요.
의도한 URL, 사이트맵 항목, 내부 링크 간의 의미 있는 차이를 조사하세요.
라우팅 또는 CMS 변경 후 생성된 사이트맵과 나열된 URL 샘플을 확인하세요.
성능을 측정하고 감사를 제도화하세요
가능한 경우 필드 데이터를 사용하고, 재현을 위해 실험실 테스트를 활용하여 Core Web Vitals(핵심 웹 사용성)를 조사하세요: 로딩은 Largest Contentful Paint, 반응성은 Interaction to Next Paint, 시각적 안정성은 Cumulative Layout Shift를 확인합니다. 평균은 깨진 고가치 템플릿을 숨길 수 있으므로 페이지 유형과 디바이스별로 분류하세요.
이미지, CSS 및 JavaScript, 서드파티 태그, 폰트, 임베드, 캐싱을 통해 느리거나 불안정한 전달을 추적하세요. 하나의 측정된 변경만 수행한 다음 렌더링과 사용자 흐름을 재확인하세요. 필드 데이터는 실제 사용자를 반영하고 실험실 데이터는 재현을 돕습니다. 어느 쪽도 모든 미래 크롤러나 방문자를 예측하지는 않습니다. 위험한 릴리스 후에는 집중 회귀 검사를 반복하고, 마이그레이션이나 플랫폼 변경 후에는 더 광범위한 감사를 수행하세요.
수익에 중요한 템플릿이나 많이 사용되는 템플릿의 실패를 먼저 수리하세요.
종료 전에 응답, canonical, 렌더된 콘텐츠, 사이트맵 상태 및 관련 성능 증거를 재확인하세요.