도메인 변경, 메타데이터 누락이 SEO 페널티 되지 않도록

도메인을 kpop.hedvion.com에서 kpopdex.com으로 통으로 갈아 엎었다. 단순 DNS 레코드 수정이 아니라 SEO와 크롤링 관점에서 검색 엔진이 혼동하지 않도록 모든 메타데이터를 동시에 갱신해야 하는 작업이었다.

처음엔 "상수 한두 개 바꾸면 되겠네" 정도로 생각했다가, 실제로는 몇 배 더 광범위한 작업이었다. 도메인 변경은 단순히 설정 파일 몇 개가 아니라 검색 엔진과 외부 시스템이 읽는 모든 메타데이터—canonical 태그, sitemap, OG 태그, hreflang, 심지어 iCalendar 피드까지—를 동시에 맞춰야 한다. 하나라도 놓치면 중복 콘텐츠로 판단되거나 구버전 도메인이 계속 색인되는 악재가 생긴다.

왜 canonical 도메인이 중요한가

검색 엔진 입장에서는 같은 콘텐츠가 여러 URL로 존재하는 것을 싫어한다. kpop.hedvion.com/artist/xyz와 kpopdex.com/artist/xyz가 정확히 같은 페이지를 서빙한다면? 어느 쪽을 색인할지, 어느 쪽에 링크 수를 누적할지 판단해야 한다. 이때 canonical 태그가 "이 페이지의 정식 주소는 이것"이라고 명시하는 신호가 된다.

<!-- 구 도메인 -->
<link rel="canonical" href="https://kpop.hedvion.com/artist/bts" />

<!-- 신 도메인 -->
<link rel="canonical" href="https://kpopdex.com/artist/bts" />

OG 태그도 마찬가지다. SNS에서 링크를 공유했을 때 미리보기 이미지와 제목을 가져오는데, OG 태그에 잘못된 도메인이 박혀 있으면 구 도메인이 계속 노출된다. 그 과정에서 외부인들이 구 도메인으로 유입되고, 검색 엔진은 둘 다 중요한 페이지로 판단한다.

변경 범위와 파일별 역할

이번 작업에서 손을 댄 파일들:

Astro 같은 정적 사이트 생성기를 쓰면 빌드 시점에 이 상수들이 HTML에 인라인된다. 즉, 한 번 빌드되면 바꿀 수 없다. 그래서 어딜 봐도 일관성 있게 새 도메인을 박아야 한다. 혹은 빌드 타임 변수로 환경별로 다른 도메인을 쓰도록 했어야 하는데, 여긴 이미 고정값으로 가고 있던 구조였다.

SEO 마이그레이션 체크리스트

이런 류의 도메인 변경을 할 때 실수하기 쉬운 포인트들:

• Canonical 태그: 각 페이지가 "내가 정식 URL이다"라고 선언해야 함
• Sitemap: robots.txt와 sitemap에 명시된 URL들도 새 도메인이어야 함. 구 도메인 sitemap이 계속 배포되면 검색 엔진이 혼동함
• OG/Twitter 태그: SNS 미리보기에서 도메인이 섞여 보임
• hreflang: 다국어 사이트라면 언어별 페이지 링크도 모두 새 도메인으로. 구 도메인을 hreflang 대상으로 두면 구 도메인을 방문하도록 유도하는 셈
• ICS/RSS 피드: 외부 구독자나 캘린더 앱이 이벤트 URL을 클릭할 때 도메인이 섞여 있으면 신 도메인 유입이 분산됨
• robots.txt와 .htaccess: 구 도메인에서 신 도메인으로 HTTP 리다이렉트를 설정했는지도 확인 필요 (이 변경에는 포함 안 된 것 같지만, 실제 배포 시 중요)

팀 관점에서의 경험담

이 작업을 하면서 느낀 점은, 도메인 변경 같은 "작고 간단해 보이는" 결정이 실제로는 여러 시스템의 일관성 체크를 필요로 한다는 것이다. 내가 정말 제대로 다 바꿨는지 확인하려면:

1. 빌드 후 생성된 HTML 파일을 몇 개 열어서 canonical과 OG 도메인이 제대로 박혔는지 확인
2. 생성된 sitemap.xml 그 자체를 열어서 URL들이 새 도메인인지 확인
3. ICS 파일도 텍스트로 열어서 이벤트 URL이 신 도메인으로 정의됐는지 확인

이런 "눈으로 확인"은 테스트 코드로 자동화하기 좋은 후보다. 실제로 Astro에서 빌드할 때 모든 canonical/OG/sitemap URL이 설정된 BASE_URL과 일치하는지 체크하는 통합 테스트를 추가해두면, 다음에 누가 도메인을 바꾸거나 환경을 추가할 때 휴먼 에러를 줄일 수 있다.

또 하나, 팀 내에서 이 변경이 배포될 때는 "DNS 레코드 변경 → CDN 캐시 무효화 → Sitemap 재제출"까지 한 묶음으로 계획해야 한다. 코드만 배포되고 sitemap이 제때 Google Search Console에 재제출되지 않으면 며칠간 구 도메인이 색인에 남아 있을 수 있다. 그 동안 유입이 분산되고, 신 도메인 페이지의 검색 순위 형성이 늦어진다.

이런 "작은 버그 fix 같지만 큰 영향"을 미치는 작업들을 팀과 함께할 때는 체크리스트와 배포 절차를 명확히 해두고, 번번이 누군가 빠뜨릴 가능성이 높으면 자동화나 코드 리뷰 가이드를 정해두는 게 좋다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.