블로그 분석을 하다가 이상한 점을 발견했다. curl로 홈페이지를 요청하니 TLS 인증서 오류가 났고, 인증서 검사를 끄고 다시 요청하니 “만료된 도메인 · Expired Domain” 이라는 안내 페이지가 돌아왔다. 그 페이지에는 <meta name=\"robots\" content=\"noindex, nofollow\">까지 붙어 있었다. 검색엔진에는 “이 사이트는 색인하지 마라”는 신호를, 방문자에게는 보안 경고를, 애드센스에는 광고를 낼 곳이 없다는 결과를 동시에 주고 있었던 셈이다.
이 글은 도메인 만료를 진단하고, 복구 대신 새 도메인(bottlehs.dev)으로 이전하면서 검색 노출과 애드센스를 최대한 빨리 되살리기 위해 한 일을 순서대로 정리한 기록이다. 같은 일을 겪는 사람이 그대로 따라 할 수 있도록 명령어와 코드를 함께 남긴다.
가장 헷갈렸던 부분은 운영자 본인의 브라우저에서는 사이트가 정상으로 보였다는 점이다. 이 블로그는 Gatsby의 gatsby-plugin-offline을 쓰고 있어서 서비스 워커가 페이지를 캐시한다. 한 번 방문한 브라우저는 네트워크가 실패해도 캐시된 앱 셸과 페이지를 보여 줄 수 있다. 그래서 “사이트가 죽었다”는 사실을 운영자가 가장 늦게 알게 되는 구조가 된다.
도메인 상태를 확인할 때는 다음 중 하나로 봐야 한다.
\ncurl, dig, whoisdig +short NS bottlehs.com\n# expired-domain-1.ns.eliv-dns.kr.\n# expired-domain-2.ns.eliv-dns.kr.네임서버 이름에 expired-domain이 들어 있다. 등록기관이 만료된 도메인의 네임서버를 자기 주차 서버로 바꿔 놓은 것이다. 로컬 DNS 캐시 문제가 아닌지 확인하려면 공용 DNS와 레지스트리 원본까지 물어본다.
# 공용 DNS 여러 곳\ndig @8.8.8.8 +short NS bottlehs.com\ndig @1.1.1.1 +short NS bottlehs.com\n\n# .com 레지스트리(권한 서버)에 직접 질의 — 여기서도 같으면 캐시 문제가 아니다\ndig @a.gtld-servers.net NS bottlehs.com +norecwhois bottlehs.com | grep -iE 'expir|name server|updated'이때 레지스트리 만료일과 등록기관 만료일이 다르게 나올 수 있다. 레지스트리는 만료 직후 자동으로 1년을 연장해 두고(Auto-Renew Grace), 등록기관이 유예 기간 안에 그 연장을 취소하거나 확정하는 방식으로 운영되는 경우가 많기 때문이다. 레지스트리 만료일이 미래로 나온다고 해서 “아직 내 도메인”이라고 판단하면 안 된다. 등록기관의 만료일과 네임서버 상태를 기준으로 본다.
\nVercel에 연결된 도메인이라면 CLI로 상태를 볼 수 있다.
\nvercel domains inspect bottlehs.com“This Domain is not configured properly”와 함께 현재 네임서버에 ✘ 표시가 나오면, 배포는 정상이고 도메인이 Vercel을 가리키지 않는 것이 문제라는 뜻이다.
\n도메인이 만료된 뒤에는 대략 다음 단계를 거친다. 기간과 비용은 TLD와 등록기관마다 다르므로 반드시 사용 중인 등록기관의 정책을 확인해야 한다.
\n| 단계 | \n대략적인 기간 | \n되살리는 방법 | \n비용 | \n
|---|---|---|---|
| 갱신 유예(Grace) | \n만료 후 수십 일 이내 | \n일반 갱신 | \n보통 갱신비 수준 | \n
| 복구 유예(Redemption) | \n이후 약 30일 | \n복구 신청 | \n갱신비 + 복구 수수료(수배 이상일 수 있음) | \n
| 삭제 대기(Pending Delete) | \n약 5일 | \n불가 | \n— | \n
| 재등록 가능 | \n이후 | \n신규 등록(선점 경쟁) | \n신규 등록비 | \n
이번에는 이미 복구 유예 단계여서 복구 비용이 신규 도메인보다 훨씬 비쌌다. 판단 기준은 다음과 같이 정리했다.
\n| 기준 | \n복구가 유리 | \n새 도메인이 유리 | \n
|---|---|---|
| 외부 백링크 | \n많고 가치가 크다 | \n거의 없다 | \n
| 브랜드 인지도 | \n도메인 자체가 브랜드다 | \n이름만 유지하면 된다 | \n
| 복구 비용 | \n감당 가능 | \n신규 대비 과도함 | \n
| 이미 떨어진 색인 | \n아직 대부분 남아 있음 | \n이미 상당 부분 빠짐 | \n
결국 같은 이름에 TLD만 바꾼 bottlehs.dev를 새로 샀다. .dev는 HSTS preload 목록에 포함된 TLD라 HTTPS가 강제되어, 개발 블로그로서 보안 측면의 장점도 있다.
도메인을 바꾸려고 코드를 검색해 보니 bottlehs.com이 여러 파일에 흩어져 있었다.
grep -rn \"bottlehs\\.com\" --exclude-dir={node_modules,public,.cache,.git} .gatsby-meta-config.js의 siteUrlgatsby-config.js의 canonical 플러그인 설정, RSS 피드 linkvercel.json의 리다이렉트 규칙설정은 siteUrl 하나만 바꾸면 되도록 모았다. 환경 변수로도 덮어쓸 수 있게 해 두면 프리뷰 환경에서도 유용하다.
// gatsby-meta-config.js\n// 사이트 도메인은 이 값 하나로 관리한다 (canonical·sitemap·RSS·OG·JSON-LD 공통)\nconst siteUrl = (process.env.SITE_URL || `https://www.bottlehs.dev`).replace(/\\/$/, ``)\n\nmodule.exports = {\n siteUrl,\n // ...\n}// gatsby-config.js — 하드코딩 대신 metaConfig 참조\n{\n resolve: `gatsby-plugin-canonical-urls`,\n options: { siteUrl: metaConfig.siteUrl },\n},본문의 내부 링크는 상대 경로로 바꿨다. 다음에 도메인이 또 바뀌어도 링크가 깨지지 않는다.
\n<!-- 나쁜 예: 도메인이 바뀌면 전부 죽은 링크가 된다 -->\n[ES6 화살표 함수](https://www.bottlehs.com/javascript/es6-arrow-function/)\n\n<!-- 좋은 예: 도메인과 무관하게 동작한다 -->\n[ES6 화살표 함수](/javascript/es6-arrow-function/)Vercel 프로젝트에 bottlehs.dev와 www.bottlehs.dev를 추가하고, 루트 도메인은 www로 리다이렉트되게 설정했다. DNS는 등록기관(또는 Cloudflare 등 DNS 서비스)에서 Vercel이 안내하는 레코드를 넣으면 된다. 인증서는 Vercel이 자동으로 발급한다.
연결이 끝나면 반드시 실제 응답으로 확인한다.
\ncurl -sI https://bottlehs.dev | grep -iE '^(HTTP|location)'\n# HTTP/2 308\n# location: https://www.bottlehs.dev/\n\ncurl -s -o /dev/null -w \"%{http_code}\\n\" https://www.bottlehs.dev/\n# 200옛 도메인은 호스팅 프로젝트에서 제거했다. 더 이상 내 소유가 아닌 도메인을 붙들고 있을 이유가 없다.
\n가장 아쉬운 부분이 여기다. 구글 서치콘솔에는 주소 변경(Change of Address) 도구가 있지만, 이 도구는 옛 사이트에서 새 사이트로 301 리다이렉트가 걸려 있어야 쓸 수 있다. 옛 도메인을 잃었으니 리다이렉트를 걸 수 없고, 따라서 기존 색인의 신호를 넘겨받을 수도 없다. 새 사이트로 처음부터 색인받는 것이 현실적인 선택이다.
\n그래서 할 수 있는 일은 “새 사이트를 최대한 빨리, 깔끔하게 크롤링되게 만드는 것”이다.
\nsitemap.xml을 제출하고, robots.txt에 Sitemap: 줄을 명시한다.lastmod를 넣는다.4번은 새 도메인일수록 중요하다. 신규 사이트는 크롤러가 한 번에 가져가는 양이 많지 않은데, 이 블로그는 사이트맵 URL 927개 중 739개가 태그 페이지였다. 크롤러가 태그 페이지부터 돌다가 정작 글을 늦게 가져갈 수 있는 구조였다. 정리 과정은 Gatsby 블로그 GEO·AEO 적용기에 따로 정리했다.
\n애드센스는 계정 단위와 사이트 단위를 나눠서 생각하면 정리가 쉽다.
\n| 항목 | \n단위 | \n도메인 변경 시 | \n
|---|---|---|
게시자 ID(ca-pub-…) | \n계정 | \n그대로 | \n
| 광고 단위(슬롯 ID) | \n계정 | \n그대로 재사용 | \n
ads.txt 내용 | \n계정 | \n같은 내용을 새 도메인 루트에 제공 | \n
| 사이트 승인 | \n사이트 | \n새로 추가하고 심사받아야 함 | \n
진행 순서는 다음과 같다.
\nhttps://새도메인/ads.txt가 200으로 열리는지 확인한다.<head>의 애드센스 코드 스니펫이나 google-adsense-account 메타 태그로 한다.승인 전에는 수동 광고 단위가 빈 영역으로만 남는다. 이 블로그는 글마다 광고 영역이 세 개라 레이아웃이 어색해졌다. 그래서 스크립트와 소유권 메타 태그는 유지하고, 광고 단위만 환경 변수로 끄는 방식을 택했다.
\n// src/constants/adsense.js\n// 심사 기간에는 배포 환경에서 GATSBY_ADSENSE_UNITS=off, 승인 후 변수를 지우면 다시 노출\nexport const ADSENSE_UNITS_ENABLED = process.env.GATSBY_ADSENSE_UNITS !== \"off\"// src/components/adsense.js\nif (!ADSENSE_UNITS_ENABLED || !adSlot) {\n return null\n}Gatsby에서 GATSBY_ 접두사가 붙은 환경 변수는 빌드 결과물(브라우저 코드)에 포함된다. 비밀값이 아니므로 호스팅 서비스에서도 “민감 정보”가 아닌 일반 변수로 등록해야 한다. 실제로 Vercel에서 민감 정보로 등록하려다 거부당했고, 일반 변수로 다시 등록했다.
| 서비스 | \n해야 할 일 | \n메모 | \n
|---|---|---|
| Disqus 댓글 | \nTrusted Domains에 새 도메인 추가 | \n댓글이 URL이 아니라 identifier(글 slug)로 연결되어 있으면 기존 댓글이 그대로 이어진다 | \n
| GA4 | \n웹 스트림 URL 수정 | \n측정 ID는 그대로 | \n
| RSS 구독자 | \n피드 주소 변경 안내 | \n옛 도메인에서 리다이렉트할 수 없으므로 공지 외에는 방법이 없다 | \n
| 소셜·프로필 링크 | \nGitHub, 이력서, 명함 등 | \n사람이 직접 바꿔야 하는 곳이 의외로 많다 | \n
이번 일의 근본 원인은 기술이 아니라 운영이다. 다음을 해 두었다.
\n모니터링은 거창할 필요 없다. 네임서버와 HTTP 상태만 확인하는 스크립트를 크론이나 CI 스케줄로 돌려도 충분하다.
\n#!/usr/bin/env bash\n# domain-check.sh — 네임서버가 바뀌었거나 사이트가 200이 아니면 실패로 종료\nDOMAIN=\"bottlehs.dev\"\nEXPECTED_NS=\"cloudflare.com\"\n\nNS=$(dig +short NS \"$DOMAIN\")\nCODE=$(curl -s -o /dev/null -w '%{http_code}' \"https://www.$DOMAIN/\")\n\nif ! echo \"$NS\" | grep -q \"$EXPECTED_NS\"; then\n echo \"네임서버 이상: $NS\"; exit 1\nfi\nif [ \"$CODE\" != \"200\" ]; then\n echo \"HTTP 상태 이상: $CODE\"; exit 1\nfi\necho \"정상\"dig·whois로 실제 상태를 확인한다.siteUrl)으로 모으고, 본문 내부 링크는 상대 경로로 바꾼다.Q: 레지스트리 whois에는 만료일이 내년으로 나오는데, 왜 도메인이 만료된 건가요?
\nA: 레지스트리가 만료 시점에 자동으로 1년을 연장해 두고, 등록기관이 유예 기간 동안 그 연장을 확정하거나 취소하는 구조이기 때문이다. 등록기관 whois의 만료일과 네임서버가 실제 상태를 더 정확히 보여 준다.
Q: 옛 도메인에서 새 도메인으로 리다이렉트를 못 걸면 검색 순위는 어떻게 되나요?
\nA: 기존 색인 신호를 넘겨받을 수 없어서 새 사이트로 다시 평가받게 된다. 사이트맵 제출, 얇은 페이지 정리, 구조화 데이터 적용처럼 크롤링과 이해를 돕는 작업으로 회복 속도를 높이는 것이 현실적인 대응이다.
Q: 애드센스 광고 단위는 새로 만들어야 하나요?
\nA: 아니다. 광고 단위와 게시자 ID는 계정에 속하므로 그대로 쓸 수 있다. 새로 해야 하는 것은 사이트 추가와 심사뿐이다.
Q: 심사 중에 광고 코드를 아예 빼 두는 게 낫지 않나요?
\nA: 소유권 확인에 쓰이는 <head>의 애드센스 스크립트나 메타 태그는 남겨 두어야 한다. 빈 칸으로 보이는 수동 광고 단위만 숨기면 심사와 사용자 경험을 둘 다 챙길 수 있다.
Q: 서비스 워커 때문에 문제를 늦게 알았다면, 오프라인 플러그인을 빼야 하나요?
\nA: 꼭 그럴 필요는 없다. 오프라인 캐시는 방문자 경험에 도움이 된다. 다만 운영자는 캐시가 없는 환경에서 사이트를 확인해야 하고, 외부 모니터링을 두는 것이 더 근본적인 해결책이다.