관찰 지점을 네 개로 나눕니다
개발자 도구의 Elements 패널은 자바스크립트가 바꾼 현재 DOM입니다. 반면 curl이나 ‘페이지 소스 보기’는 서버가 처음 보낸 HTML에 가깝습니다. 두 결과가 다르면 크롤러의 렌더링 능력과 시점에 따라 노출도 달라질 수 있습니다.
CDN이 이전 HTML을 유지하거나 소셜 플랫폼이 OG 값을 장기간 캐시할 수도 있습니다. 각 관찰 지점의 응답 시각, 캐시 헤더, 최종 URL을 함께 저장해야 같은 문서를 비교할 수 있습니다.
리다이렉트 체인부터 고정합니다
www와 apex, HTTP와 HTTPS, 언어 자동 이동이 섞이면 테스트 도구마다 다른 최종 URL을 볼 수 있습니다. 한 번의 영구 리다이렉트로 대표 호스트에 도달하고, locale 경로 이후의 canonical은 자기 자신을 가리키게 합니다.
미리보기 봇이 쿠키를 저장하지 않는다는 점도 고려합니다. 쿠키가 없을 때의 기본 언어와 x-default 경로가 일관되어야 테스트 결과가 재현됩니다.
중복 생성 주체를 제거합니다
레이아웃, 페이지 컴포넌트, SEO 플러그인이 동시에 title과 canonical을 만들면 순서에 따라 값이 달라집니다. 사이트 공통 기본값과 페이지 고유 값의 책임을 하나의 메타데이터 함수로 모읍니다.
Open Graph와 X 카드도 같은 데이터 원본에서 만듭니다. 표시되는 제목과 구조화 데이터의 headline이 크게 다르면 어느 것이 현재 페이지를 설명하는지 불분명해집니다.
캐시 무효화는 마지막 단계입니다
원본이 틀린 상태에서 캐시만 지우면 잘못된 값을 더 빠르게 다시 저장합니다. 배포 응답의 최종 HTML과 헤더가 맞는지 먼저 확인한 뒤 플랫폼별 디버거를 사용합니다.
변경 시각, 배포 식별자, 확인한 URL, 관찰된 값을 기록하면 ‘기다리면 된다’와 실제 회귀를 구분할 수 있습니다. 자동 테스트에는 canonical, hreflang, title, description의 고유성을 포함합니다.
배포 전 체크리스트
- ✓ 인증·쿠키 없는 서버 HTML을 저장했는가?
- ✓ 서버 HTML과 렌더링 DOM을 비교했는가?
- ✓ 리다이렉트의 최종 URL과 canonical이 일치하는가?
- ✓ 페이지 메타데이터를 만드는 코드가 한 곳인가?
- ✓ 원본 확인 후 외부 플랫폼 캐시를 갱신했는가?
자주 묻는 질문
브라우저에는 맞는데 검색 미리보기만 틀린 이유는?
크롤러 캐시, 서버 HTML과 DOM의 차이, 다른 최종 URL, 접근 차단이 흔한 원인입니다. 새 서버 응답부터 순서대로 비교하세요.
배포 뒤 바로 다시 크롤링 요청을 해야 하나요?
먼저 공개 응답을 검증한 뒤 요청하세요. 원본이 틀린 상태에서 재수집하면 잘못된 값의 수명만 늘릴 수 있습니다.