웹사이트 SEO 론칭 체크리스트: 배포 후 첫 48시간
배포가 오후 2시 47분에 시작된다. 빌드가 통과한다. DNS가 네임서버를 통해 전파된다. 도메인이 해석된다. 브라우저에서 홈페이지가 로드된다—폰트가 렌더링되고, 이미지가 나타나고, 스크립트가 실행된다. 숨을 쉰다.
그러면 두 번째 질문이 떠오른다: 다음 48시간 동안 SEO에 무슨 일이 일어나는가?
이 시간은 Google이 당신의 페이지를 며칠 내에 발견할지 아니면 수주일을 헤맬지를 결정한다. 기존 URL이 깔끔하게 리디렉션되는지 아니면 404가 색인 전체에 흩어질지를. Search Console이 첫 크롤 예산이 도착하기 전에 연결되는지 아니면 이미 손실된 후에 연결되는지를 결정한다.
아래는 모든 프로덕션 배포 후에 실행하는 정확한 48시간 체크리스트다. Search Console 인증, IndexNow 핑, 리디렉션 감사, 정규 URL 확인, 빠른 색인화와 느린 무명 상태를 분리하는 일곱 가지 기술 작업을 포함한다. 47시간을 넘었다면 어쨌든 첫 번째 작업부터 시작하자—늦은 시작이 하지 않는 것보다 낫다.
나는 수년 동안 수십 개의 사이트를 론칭했다—작은 마케팅 페이지부터 Next.js와 Astro의 대규모 헤드리스 CMS 빌드까지—그리고 론칭 후 첫 48시간은 대부분의 팀이 강한 오가닉 성장을 스스로 설정하거나 조용히 몇 개월 동안 SEO를 망치는 지점이다. 차이는 어떤 비결이 아니다. 체크리스트다. 따분하고, 방법론적이고, 중요한 체크리스트다.
이것이 그 체크리스트다. 다른 곳에서 찾을 수 있는 "콘텐츠가 좋은지 확인하세요"라는 푸석한 조언이 아니다. 첫 이틀 동안 대략적인 순서대로 해야 할 구체적이고 기술적인 것들이다.
목차
- 0-1시간: 사전 점검
- 1-2시간: robots.txt 및 Sitemap 구성
- 2-4시간: Google Search Console 설정
- 2-4시간: Bing 웹마스터 도구 및 IndexNow
- 4-8시간: 리디렉션 — 침묵의 살인자
- 4-8시간: 분석 및 추적 확인
- 8-24시간: 실제로 색인되는 것
- 24-48시간: 모니터링 및 문제 해결
- 완전한 48시간 체크리스트 테이블
- FAQ
0-1시간: 사전 점검
검색 엔진을 생각하기 전에, 기본 사항이 손상되지 않았는지 확인해야 한다. 스테이징 noindex 태그가 여전히 <head>에 있는 론칭을 본 적이 있다. 3주 후에 발견하기에는 재미있는 것이다.
남아있는 스테이징 지시문 확인
이것이 가장 흔한 실수다. 브라우저를 열고 홈페이지의 소스를 보고 다음을 검색하자:
<meta name="robots" content="noindex">
그것이 여전히 있다면, 모든 것을 멈추고 고쳐라. HTTP 헤더도 확인하자—일부 프레임워크(특히 Next.js)는 서버 수준에서 X-Robots-Tag 헤더를 설정할 수 있다:
curl -I https://yourdomain.com | grep -i robots
아무것도 보이지 않아야 한다. X-Robots-Tag: noindex를 본다면, 전체 사이트는 검색 엔진에 보이지 않으며 이 체크리스트의 다른 것은 중요하지 않다.
SSL 및 정규 URL 확인
이 네 개의 URL을 수동으로 실행하자:
http://yourdomain.comhttp://www.yourdomain.comhttps://yourdomain.comhttps://www.yourdomain.com
모두 네 개는 단일 정규 버전으로 301 리디렉션되어야 한다. 대부분의 사이트는 https://yourdomain.com(non-www, HTTPS)을 사용한다. 이들 중 하나라도 리디렉션 대신 200 응답을 제공하면, 첫 분부터 중복 콘텐츠가 있다.
페이지 제목 및 메타 설명 확인
상위 10개 페이지를 점검하자. 각각은 고유한 <title> 태그와 <meta name="description">을 가져야 한다. 나는 Screaming Frog를 사용하지만, 몇 페이지만 curl할 수도 있다:
curl -s https://yourdomain.com | grep -o '<title>[^<]*</title>'
Headless CMS 설정을 실행하고 있다면—Sanity, Contentful, Storyblok—헤드리스 CMS 개발 계층이 실제로 CMS 콘텐츠에서 이 필드를 채우고 있는지, 플레이스홀더 텍스트를 하드코딩하지 않는지 확인하자.
1-2시간: robots.txt 및 Sitemap 구성
robots.txt
robots.txt 파일은 https://yourdomain.com/robots.txt에 있다. 존재해야 하고, 올바르게 존재해야 한다.
대부분의 새로운 사이트의 경우, 다음은 모양이어야 한다:
User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml
그게 다다. 론칭 날에 복잡하게 만들지 마. 나중에 관리 페이지, 검색 결과 페이지 또는 색인할 수 없는 다른 콘텐츠에 대한 특정 disallow 규칙을 추가할 수 있다. 지금 중요한 것은:
- 모든 것을 실수로 차단하지 않는다(
Disallow: /는 핵심 옵션) - sitemap을 가리킨다
- 파일이 접근 가능하다(404가 아닌 200을 반환)
Next.js를 사용하는 경우, App Router는 robots.txt를 생성하기 위한 기본 지원을 가지고 있다:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
return {
rules: {
userAgent: '*',
allow: '/',
},
sitemap: 'https://yourdomain.com/sitemap.xml',
}
}
Astro 빌드의 경우, 보통 @astrojs/sitemap 통합을 사용하고 public/ 디렉토리에 정적 robots.txt를 생성한다.
XML Sitemap
Sitemap은 검색 엔진에 정확히 어떤 페이지가 존재하고 마지막으로 수정된 시간을 알려준다. https://yourdomain.com/sitemap.xml에 있어야 한다.
좋은 론칭 날 sitemap:
- 색인할 페이지만 포함한다(404s, 리디렉션,
noindex페이지 없음) - 올바른 정규 URL을 사용한다(HTTPS, 올바른 www/non-www)
- 정확한
<lastmod>날짜를 가진다 - sitemap 파일당 50,000 URL 미만으로 유지한다(필요한 경우 sitemap 인덱스 사용)
지금 테스트하자:
curl -s https://yourdomain.com/sitemap.xml | head -50
유효한 XML인지 확인하고, HTML 페이지가 아닌지. React 앱이 /sitemap.xml을 가로채고 앱 셸을 제공하는 것을 본적 있다. 이것은 Googlebot에 쓸모없다.
2-4시간: Google Search Console 설정
이것은 론칭 날에 당신의 가장 중요한 SEO 도구다. 건너뛰지 마. 지연시키지 마.
속성 추가
- Google Search Console로 가자
- Domain 옵션을 사용하여 속성을 추가하자(URL 접두사 아님)—이것은 모든 서브도메인과 프로토콜 변형을 포함한다
- DNS TXT 레코드를 통해 인증하자(호스팅 제공자 또는 Cloudflare이 쉽게 만든다)
Domain 수준 인증은 전파되는 데 몇 분이 걸린다. 기다리는 동안:
Sitemap 제출
인증되면, 왼쪽 사이드바의 Sitemaps로 가서 sitemap URL을 제출하자. Google이 가져가고 모든 오류를 보고할 것이다.
보통 초기 sitemap 처리는 1-4시간 내에 완료된다. Google은 발견된 URL의 수와 유효한 수를 알려준다.
주요 페이지에 대한 색인화 요청
Search Console의 맨 위에 있는 URL 검사 도구를 사용하자. 가장 중요한 URL을 붙여 넣자—홈페이지, 주요 랜딩 페이지, 상위 블로그 게시물—그리고 색인화 요청을 클릭하자.
Google은 대략 속성당 하루에 10-12개의 색인 요청으로 제한한다. 우선순위를 정하자:
- 홈페이지
- 핵심 서비스/제품 페이지
- About 페이지
- 상위 콘텐츠 페이지
Pagination 페이지, 태그 페이지 또는 보조 페이지라고 생각할 모든 것에서 요청을 낭비하지 마.
Coverage 리포트 확인
24시간 내(종종 더 빨리), Pages 리포트가 채워지기 시작할 것이다. 다음을 주시하자:
- Not indexed: Crawled - currently not indexed — Google이 페이지를 찾았지만 색인화하지 않기로 선택했다
- Not indexed: Discovered - currently not indexed — Google이 페이지가 있다는 것을 알지만 아직 크롤링하지 않았다
- Excluded by robots.txt — robots.txt가 의도하지 않은 것을 차단하고 있다
2-4시간: Bing 웹마스터 도구 및 IndexNow
예, Bing은 중요하다. 2026년 초 기준 미국 검색 트래픽의 약 9%를 처리한다. 또한 DuckDuckGo, Yahoo, 그리고 increasingly, Copilot과 ChatGPT의 AI 기반 검색 결과(Bing의 인덱스를 통한)를 지원한다.
Bing 웹마스터 도구 설정
- Bing 웹마스터 도구로 가자
- Google Search Console 설정을 직접 가져올 수 있다—Bing이 이 옵션을 제공하며 시간을 절약한다
- 여기서도 sitemap을 제출하자
Bing의 색인화는 IndexNow 때문에 종종 Google의 색인화보다 빠르다.
IndexNow 프로토콜
IndexNow는 콘텐츠가 변경될 때 검색 엔진에 즉시 알리는 푸시 기반 프로토콜이다. Bing, Yandex, 그리고 몇몇 다른 엔진이 지원한다. Google은 지원하지 않는다(아직—2022년 이후 "평가"하고 있다).
설정하는 방법은 다음과 같다:
- API 키를 생성하자(UUID 같은 문자열)
https://yourdomain.com/{your-key}.txt에 키 파일을 생성하고 키만 포함하자- IndexNow API를 핑하자:
curl "https://api.indexnow.org/indexnow?url=https://yourdomain.com/&key=your-api-key"
대량 제출:
curl -X POST "https://api.indexnow.org/indexnow" \
-H "Content-Type: application/json" \
-d '{
"host": "yourdomain.com",
"key": "your-api-key",
"urlList": [
"https://yourdomain.com/",
"https://yourdomain.com/about",
"https://yourdomain.com/services"
]
}'
많은 호스팅 플랫폼과 CMS 도구는 이제 IndexNow를 기본적으로 지원한다. Cloudflare는 IndexNow 통합을 가지고 있다. WordPress는 플러그인을 가지고 있다. Next.js 사이트를 실행하고 있다면, 빌드/배포 파이프라인 또는 CMS 웹훅 핸들러에 IndexNow 핑을 추가할 수 있다.
4-8시간: 리디렉션 — 침묵의 살인자
이것이 기록이 없는 전혀 새로운 도메인이라면, 이 섹션을 대부분 건너뛸 수 있다. 하지만 기존 사이트를 다시 론칭하는 경우—새로운 디자인, 새로운 CMS, 새로운 URL 구조—리디렉션은 론칭이 잘못되는 지점이다.
모든 기존 URL을 새로운 해당 URL에 매핑
론칭 전에, 리디렉션 맵을 가지고 있어야 한다. 론칭 후에는 작동하는지 확인해야 한다.
기존 sitemap을 가져가자(저장했지, 맞지?). 모든 URL을 테스트하자:
# 리디렉션을 빠르게 확인하는 bash 한 줄짜리
while read url; do
status=$(curl -o /dev/null -s -w "%{http_code}" -L "$url")
echo "$status $url"
done < old-urls.txt
당신이 보고 있는 것:
- 301 리디렉션 정확한 새 페이지로(302가 아님—영구 이동에는 301 사용)
- 리디렉션 체인 없음(기존 URL → 중간 URL → 최종 URL). 각 리디렉션은 직접 목적지로 가야 한다
- 리디렉션 루프 없음(URL A → URL B → URL A)
일반적인 리디렉션 함정
| 문제 | 무슨 일이 일어나는가 | 어떻게 찾나 |
|---|---|---|
| Trailing slash 리디렉션 누락 | /about와 /about/는 다른 URL |
두 변형 모두 확인 |
| 대소문자 구분 | /About vs /about |
잘못된 대소문자로 테스트 |
| 쿼리 매개변수 처리 | 기존 URL ?id=123 |
기존 매개변수화된 URL 확인 |
| Fragment 처리 | Anchors #section이 벗겨짐 |
기존 링크된 anchors 검토 |
| Mixed content 리디렉션 | HTTP → HTTPS 플러스 경로 변경 | 단일 301, 체인이 아닌 것 확인 |
Next.js에서, next.config.js에서 리디렉션을 처리한다:
module.exports = {
async redirects() {
return [
{
source: '/old-blog/:slug',
destination: '/articles/:slug',
permanent: true,
},
]
},
}
대규모 리디렉션(수백 또는 수천)의 경우, 엣지에서 처리하자—Vercel Edge Config, Cloudflare Workers, 또는 CDN의 리디렉션 규칙. 애플리케이션 config에 2,000개의 리디렉션을 놓으면 빌드 속도가 느려질 수 있다.
4-8시간: 분석 및 추적 확인
Google Analytics 4 (GA4)
GA4 속성이 모든 페이지에서 올바르게 실행되는지 확인하자. 가장 쉬운 확인:
- Chrome에서 사이트를 열자
- DevTools → Network 탭 열기
collect또는google-analytics로 필터링하자- 페이지 간 탐색—각 pageview에 대해 네트워크 요청이 보여야 한다
Single-page app(대부분의 Next.js 및 Astro 사이트는 적어도 부분적으로 그렇다)의 경우, 클라이언트 측 탐색이 pageview를 트리거하는지 확인하자. 이것은 매우 흔한 누락—초기 페이지 로드는 분석을 실행하지만, 이후 탐색은 그렇지 않다.
Next.js App Router를 @next/third-parties 패키지와 함께 사용하는 경우:
import { GoogleAnalytics } from '@next/third-parties/google'
export default function RootLayout({ children }) {
return (
<html>
<body>{children}</body>
<GoogleAnalytics gaId="G-XXXXXXXXXX" />
</html>
)
}
Google Tag Manager
GTM을 사용한다면, 컨테이너가 로드되고 태그가 실행되는지 확인하자. Tag Assistant(GTM Preview 모드)를 사용하여 디버깅하자.
Core Web Vitals 모니터링 설정
SEO 순위에 중요하다. 론칭 날 메트릭이 기준선이 될 것이다. 실제 사용자 모니터링을 설정하자:
- Google Search Console → Core Web Vitals 리포트(채워지는 데 며칠 소요)
- web-vitals JavaScript 라이브러리 실시간 데이터
- Vercel Analytics Vercel에 있다면(플랫폼에 내장, Pro $10/월)
2026년 기준, Google의 순위는 이러한 CWV 임계값을 사용한다:
| 메트릭 | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5s - 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | ≤ 200ms | 200ms - 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
참고: INP는 2024년 3월의 responsiveness 메트릭으로 FID(First Input Delay)를 대체했다. FID를 여전히 언급하는 가이드는 오래된 것이다.
8-24시간: 실제로 색인되는 것
이것은 모두가 묻는 질문이고, 답변은 당신을 놀라게 할 수 있다.
Google의 크롤 우선순위
수십 개의 론칭 경험에서, 다음은 일반적인 색인화 순서다:
- 홈페이지 — 거의 항상 첫 번째, 보통 sitemap 제출 후 4-24시간 내와 색인 요청
- 홈페이지에서 링크된 페이지 — 주요 탐색 페이지가 다음에 크롤링된다
- 외부 백링크가 있는 페이지 — 새 사이트가 다른 사이트의 링크를 이미 가지고 있다면, 그 목적지 페이지는 우선순위를 얻는다
- Sitemap 전용 페이지 — sitemap을 통해서만 발견 가능한 페이지(탐색에서 연결되지 않음)는 마지막으로 크롤링된다
색인화를 느리게 하는 것
- Thin content — 매우 적은 양의 고유 텍스트를 가진 페이지는 낮아진다
- Duplicate content — Google이 너무 유사한 페이지를 감지하면, 하나를 색인화하고 나머지를 건너뛴다
- Orphan pages — 내부 링크가 없는 페이지(sitemap에 있더라도)는 낮은 우선순위로 취급된다
- 기록이 없는 새로운 도메인 — 완전히 새로운 도메인은 시간이 오래 걸린다. 이것은 현실이다. Google은 미지의 도메인을 조심한다.
새로운 도메인의 현실적인 색인화 타임라인 (2026)
| 시간 | 예상 |
|---|---|
| 0-4시간 | Sitemap 가져오기, 홈페이지 크롤링 |
| 4-24시간 | 홈페이지 색인화, 상위 수준 페이지 크롤링 |
| 1-3일 | 주요 탐색 페이지 색인화 |
| 1-2주 | 대부분의 sitemap URL 크롤링 |
| 2-4주 | 품질 페이지의 전체 색인 범위 |
| 1-3개월 | 검색 순위 안정화 시작 |
재론칭하는 기존 도메인의 경우, 색인화가 훨씬 빠르다—보통 URL 구조를 급격히 변경하지 않았으고 리디렉션이 올바르게 작동하면 24-72시간 내에 대부분 페이지.
24-48시간: 모니터링 및 문제 해결
Google Search Console Coverage 확인
이제부터 데이터가 흐르기 시작해야 한다. Pages 리포트를 보고 문제를 해결하자:
- Soft 404s — 200을 반환하지만 Google이 오류 페이지라고 생각하는 페이지(보통 거의 콘텐츠가 없어서)
- Server errors (5xx) — 브라우저에서 사이트가 좋아 보여도 Googlebot에 오류를 반환하는 사이트(공격적인 속도 제한 또는 봇 감지로 발생할 수 있음)
- Redirect errors — 깨진 리디렉션 체인 또는 루프
404s 모니터링
서버 로그 또는 분석을 확인하여 404 오류. 실제 사용자와 검색 엔진이 존재하지 않는 URL을 클릭하고 있다. 재론칭의 경우, 각 404는 링크 에퀴티를 잃고 있는 누락된 리디렉션이다.
주요 페이지를 가져오고 렌더링
URL 검사 도구의 Live Test 기능을 사용하여 Google이 페이지를 정확히 어떻게 렌더링하는지 보자. 이것은 JavaScript 기반 사이트에 중요하다. 중요한 콘텐츠에 클라이언트 측 렌더링을 사용하면, Google이 보지 못할 수도 있다.
이것은 종종 콘텐츠가 많은 사이트에 서버 측 렌더링 또는 정적 생성을 추천하는 한 가지 이유다. Next.js 개발 및 Astro 개발 작업은 거의 항상 정확히 이 이유로 SSR 또는 SSG를 사용한다.
완전한 48시간 체크리스트 테이블
| 시간 | 작업 | 우선순위 | 도구 |
|---|---|---|---|
| 0시간 | Staging noindex 태그 제거 | Critical | View source, curl |
| 0시간 | SSL 및 정규 리디렉션 확인 | Critical | Browser, curl |
| 0시간 | 페이지 제목 및 메타 설명 점검 | High | Screaming Frog, curl |
| 1시간 | robots.txt가 접근 가능하고 올바른지 확인 | Critical | Browser |
| 1시간 | XML sitemap이 유효하고 완성되었는지 확인 | Critical | Browser, XML validator |
| 2시간 | Google Search Console 설정 | Critical | GSC |
| 2시간 | Google에 sitemap 제출 | Critical | GSC |
| 2시간 | 상위 10페이지에 대한 색인화 요청 | High | GSC URL Inspection |
| 3시간 | Bing 웹마스터 도구 설정 | High | Bing |
| 3시간 | IndexNow 구현 | Medium | API, hosting config |
| 4시간 | 모든 리디렉션 확인(재론칭만 해당) | Critical | curl, Screaming Frog |
| 4시간 | GA4가 모든 페이지를 추적하는지 확인 | High | GA4 Real-time, DevTools |
| 4시간 | Core Web Vitals 모니터링 설정 | Medium | GSC, web-vitals |
| 8시간 | GSC에서 초기 크롤 통계 확인 | High | GSC |
| 24시간 | GSC coverage 리포트 검토 | High | GSC |
| 24시간 | 로그/분석에서 404 오류 확인 | High | Server logs, GA4 |
| 48시간 | 주요 페이지를 가져오고 렌더링 테스트 | Medium | GSC URL Inspection |
| 48시간 | 색인화된 페이지 수가 예상과 일치하는지 확인 | High | site:yourdomain.com |
FAQ
Google이 2026년에 새 웹사이트를 색인화하는 데 얼마나 걸리나?
완전히 새로운 도메인의 경우, Google Search Console을 통해 sitemap을 제출하고 색인화를 요청하면 24시간 내에 홈페이지가 색인화될 것으로 예상하자. 전체 사이트 색인화는 일반적으로 2-4주가 걸린다. 재론칭하는 기존 도메인은 보통 3-7일 내에 전체 재색인화를 본다. 이러한 타임라인은 이 체크리스트에서 모든 것을 완료했다고 가정한다—Search Console 제출 없이, 새로운 도메인은 Google이 발견하기 전에 몇 주를 기다릴 수 있다.
Google에 사이트를 제출해야 할까 아니면 자연스럽게 발견되기를 기다려야 할까?
항상 적극적으로 제출하자. "Google이 당신을 찾도록 하자"라는 아이디어는 10년 전의 구식 조언이다. Google Search Console을 통해 sitemap을 제출하고 URL Inspection 도구를 사용하여 가장 중요한 페이지에 대한 색인화를 요청하자. 단점은 전혀 없으며 며칠 또는 주의 발견을 가속화한다.
IndexNow가 Google과 작동하나?
아니다, 2026년 중반 기준 아직 아니다. Google은 2021년 말부터 IndexNow를 평가해왔지만 공식적으로 채택하지 않았다. IndexNow는 현재 Bing, Yandex, Naver 및 몇몇 다른 사이트와 작동한다. 여전히 구현할 가치가 있다. Bing의 인덱스가 DuckDuckGo, Yahoo Search를 사용하고 Microsoft Copilot과 (부분적으로) ChatGPT의 AI 보조자에 의해 사용되기 때문이다.
SEO의 301과 302 리디렉션의 차이는 무엇인가?
301은 영구 리디렉션이며 대부분의 링크 에퀴티(순위 파워)를 목적지 URL로 전달한다. 302는 임시이며 원본 URL이 돌아올 수 있으므로 검색 엔진은 순위 신호를 전달할 가능성이 낮다고 알린다. 사이트 재론칭 및 역전할 계획이 없는 URL 변경의 경우, 항상 301을 사용하자. 일부 프레임워크에서 302가 기본값이어서 팀이 실수로 302를 사용하는 것을 본다.
Google Search Console에서 내 페이지가 'Discovered - currently not indexed'를 표시하는 이유는?
Google이 페이지를 안다(sitemap 또는 내부 링크에서)는 의미이지만 아직 크롤링하지 않았다. 새로운 사이트의 경우, 처음 며칠 동안 정상이다—Google은 URL을 큐에 두고 우선순위에 따라 크롤링한다. 페이지가 2-3주 이상 이 상태에 머물면, 보통 Google이 충분히 높은 우선순위라고 생각하지 않는다. 내부 링크 개선 및 이들 페이지에 고유하고 가치있는 콘텐츠 추가가 도움이 된다.
Google Search Console과 Bing 웹마스터 도구가 모두 필요한가?
예. 다양한 검색 엔진을 처리하고 다양한 데이터를 제공한다. Google Search Console은 대부분의 시장에서 약 90%의 검색 트래픽을 포함하지만, Bing 웹마스터 도구는 나머지와 IndexNow 통합 접근을 포함하며, 이는 Bing 기반 엔진에서 색인화를 가속화할 수 있다. Bing에 대한 설정은 GSC 구성을 직접 가져올 수 있으므로 약 5분이 걸린다.
내 JavaScript 콘텐츠가 Google에서 색인화되는지 어떻게 확인하나?
Google Search Console의 URL Inspection 도구를 사용하고 'Test Live URL'을 클릭하자. 그러면 렌더링된 HTML을 본다—이것은 Googlebot이 JavaScript를 실행한 후 정확히 무엇을 보는지 보여준다. 중요한 콘텐츠가 렌더링된 출력에서 누락되면, 그 콘텐츠에 대해 서버 측 렌더링으로 전환해야 한다. 이것은 특히 클라이언트 측에서 콘텐츠를 가져오는 React SPA에서 흔하다. Next.js 및 Astro 같은 프레임워크는 SSR 및 SSG로 즉시 이를 잘 처리한다.
론칭 날에 AI 크롤러를 robots.txt에서 차단해야 할까?
이것은 비즈니스에 따라 다른 판단이다. GPTBot(OpenAI), ClaudeBot(Anthropic), Google-Extended(Gemini 훈련) 같은 봇은 robots.txt를 통해 차단할 수 있다(AI 훈련을 위해 콘텐츠를 사용하지 않으려면). 하지만 GPTBot을 차단하면 ChatGPT의 검색 결과에서 콘텐츠가 나타나지 않을 수 있다. 내 추천: 모든 것을 허용하며 론칭하자, AI 크롤러의 서버 부하를 모니터링하자, 필요하면 선택적으로 차단을 추가하자. 이 결정을 론칭을 지연시키지 마—나중에 항상 robots.txt를 업데이트할 수 있다.
사이트 론칭을 계획하고 있으며 처음부터 기술 SEO 기초를 올바르게 하려면, 연락하거나 가격을 확인하자. 이 항목을 잘못하는 것은 나중에 수정하기에 비싸다. 처음부터 올바르게 하는 것이 훨씬 저렴하다.