도입: 사이트맵과 robots.txt를 함께 점검해야 하는 이유
Next.js App Router에서는 app/sitemap.ts와 app/robots.ts를 이용해 두 파일을 코드로 생성할 수 있다. 사이트맵은 검색 엔진에 공개 URL 목록을 전달하고, robots.txt는 크롤러가 접근해도 되는 경로와 사이트맵 위치를 알린다. 파일을 만들었다는 사실보다 배포된 주소에서 올바른 응답이 나오는지 확인하는 과정이 중요하다.
Next.js App Router 사이트맵과 robots.txt 핵심 점검 항목
1. 파일 위치와 내보내기 형식
- 확인 대상:
app/sitemap.ts와app/robots.ts가 App Router의app루트에 있고 기본 함수를 내보내는지 확인한다. - 확인 방법: 두 파일이 각각
MetadataRoute.Sitemap,MetadataRoute.Robots타입에 맞는 값을 반환하는지 편집기와 빌드 결과로 점검한다. - 실패 신호: 빌드에서 타입 오류가 나거나 배포 후
/sitemap.xml,/robots.txt가 404를 반환한다. - 조치: 파일명과 위치를 바로잡고 기본 내보내기를 사용한 뒤 다시 빌드한다.
2. 사이트맵 URL의 절대 주소
- 확인 대상: 사이트맵의 각
url값이 운영 도메인을 포함한 절대 URL인지 확인한다. - 확인 방법: 배포된
/sitemap.xml을 열어<loc>값이https://로 시작하고 실제 페이지로 연결되는지 확인한다. - 실패 신호: localhost, 미리보기 도메인, 상대 경로가 포함되거나 링크가 404로 끝난다.
- 조치: 운영 환경의 기준 URL을 환경 변수 한 곳에서 읽도록 만들고, 게시된 글의 slug와 조합한다.
3. 동적 글 목록의 누락과 중복
- 확인 대상: 공개 상태인 글만 포함되고 같은 URL이 두 번 들어가지 않는지 확인한다.
- 확인 방법: 콘텐츠 원본의 공개 글 수와 XML의 글 URL 수를 비교하고, URL을 집합으로 변환해 중복을 검사한다.
- 실패 신호: 초안이나 삭제된 글이 노출되거나 새 글이 배포된 뒤에도 목록에 나타나지 않는다.
- 조치: 글을 읽는 함수의 필터 조건을 통일하고, 정렬·중복 제거 뒤 사이트맵 항목을 반환한다.
4. lastModified 값의 의미
- 확인 대상:
lastModified가 요청 시각이 아니라 실제 콘텐츠 변경 시각을 나타내는지 확인한다. - 확인 방법: 원고의 수정일과 XML의
<lastmod>값을 비교하고, 변경하지 않은 글이 매 배포마다 갱신되지 않는지 살핀다. - 실패 신호: 모든 URL의 수정일이 항상 현재 시각으로 바뀌어 검색 엔진에 의미 없는 변경 신호를 보낸다.
- 조치: frontmatter나 저장소 이력 등 프로젝트가 신뢰하는 수정일 데이터를 사용하고, 값이 없을 때의 정책을 명시한다.
5. robots 규칙과 사이트맵 주소
- 확인 대상: 공개 페이지는 허용하고 관리자·미리보기 등 비공개 경로는 필요한 범위에서 제외했는지,
sitemap값이 운영 URL인지 확인한다. - 확인 방법:
/robots.txt원문을 열어User-agent,Allow,Disallow,Sitemap줄을 읽고 각 경로를 직접 요청한다. - 실패 신호:
Disallow: /처럼 전체 사이트를 막거나, Sitemap 줄이 개발 주소를 가리킨다. - 조치: 기본 규칙을 최소화하고 환경별 기준 URL을 공유한다. 비공개 정보 보호를 robots.txt에만 의존하지 말고 인증도 적용한다.
6. 배포 결과와 캐시
- 확인 대상: 로컬 코드가 아니라 실제 운영 배포에서 최신 XML과 텍스트가 제공되는지 확인한다.
- 확인 방법: 배포 직후 브라우저와
curl로 두 URL의 상태 코드, 본문, 응답 헤더를 확인하고 새 글 URL을 검색한다. - 실패 신호: 코드 변경 후에도 이전 내용이 계속 나오거나 CDN과 원본의 응답이 다르다.
- 조치: Next.js의 메타데이터 라우트 캐시 특성과 프로젝트의 재검증 설정을 확인하고, 필요한 경우 새 배포 또는 명시적인 재검증을 수행한다.
점검 순서
먼저 두 파일의 위치와 반환 타입을 확인하고 빌드를 통과시킨다. 다음으로 운영 환경에서 /sitemap.xml과 /robots.txt를 직접 연다. 사이트맵 URL의 도메인·상태 코드·중복·공개 여부를 확인한 뒤 robots 규칙과 Sitemap 줄을 대조한다. 마지막으로 새 글 하나를 게시해 사이트맵 반영과 캐시 갱신까지 확인하면 설정과 운영 검증을 한 번에 마칠 수 있다.
자주 놓치는 포인트
robots.txt의 허용 여부와 검색 결과 노출 여부는 같은 개념이 아니다. 또한 robots.txt는 접근 제어 장치가 아니므로 민감한 경로는 인증으로 보호해야 한다. 사이트맵의 priority나 changeFrequency를 넣는 것보다 실제 공개 URL과 수정일이 정확한지가 우선이다. 프록시나 미들웨어를 사용한다면 메타데이터 파일 경로가 불필요하게 가로채지지 않는지도 확인한다.
재사용 체크리스트
- [ ]
/sitemap.xml과/robots.txt가 운영 환경에서 200으로 응답한다. - [ ] 사이트맵의 모든 URL이 운영 도메인의 절대 주소다.
- [ ] 초안·삭제 글은 빠지고 공개 글은 누락되지 않았다.
- [ ]
lastModified는 실제 변경 시각을 반영한다. - [ ] robots 규칙이 전체 사이트를 실수로 차단하지 않는다.
- [ ] robots.txt의 Sitemap 줄이 실제
/sitemap.xml을 가리킨다. - [ ] 새 글 게시 후 사이트맵과 캐시 갱신을 확인했다.
참고 자료
- Next.js 공식 문서: Metadata Files
- Next.js 공식 문서: robots.txt
- Next.js 공식 문서: sitemap.xml