Next.js 15 App Router로 SEO 최적화하기
Next.js 15 App Router의 메타데이터 병합, 서버 HTML, canonical, sitemap, JSON-LD를 한 데이터 기준으로 검수하는 SEO 실전 가이드입니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
Next.js 15 App Router의 SEO는 메타 태그를 채우는 작업이 아니라 공개 URL, 서버가 내보내는 본문, canonical, sitemap, 구조화 데이터를 같은 페이지 레코드에 맞추는 일입니다. App Router를 쓴다는 사실만으로 색인이나 순위가 보장되지는 않습니다.
먼저 검색엔진이 받아야 할 결과를 정하십시오. 사용자가 특정 질문으로 들어왔을 때 고유한 제목과 답이 있고, 그 답을 대표하는 URL이 하나이며, 페이지가 삭제되거나 비공개가 되면 색인 신호도 함께 바뀌어야 합니다. 구현 API는 이 계약을 지키기 위한 수단입니다.
라우트별 검색 계약부터 적으십시오#
| 대상 | 고유 데이터 | 색인 조건 | 실패 신호 |
|---|---|---|---|
| 정적 소개 | 제목·요약·대표 이미지 | 항상 공개 | 모든 페이지가 같은 설명 |
| 블로그 상세 | slug·본문·발행일·수정일 | 발행 상태 | 목록에는 있고 상세는 404 |
| 상품 상세 | 상품명·옵션·재고 상태 | 판매·보존 정책 | 품절 때 URL을 즉시 삭제 |
| 필터 목록 | 필터 조합·페이지 번호 | 대표 조합만 | 무한 조합이 모두 색인 |
D 운영 가설로는 화면을 만들기 전에 이 표를 데이터 모델 옆에 두는 방식이 효과적입니다. 예를 들어 글의 공개 상태를 바꿀 때 상세 응답, 목록, sitemap, 내부 링크가 어떤 순서로 바뀌는지 한 사건으로 정의해야 오래된 URL이 남지 않습니다. 사이트 전체 점검 항목은 홈페이지 SEO 개발 체크리스트와 함께 볼 수 있습니다. 라우트와 콘텐츠 운영 범위를 처음 정하는 단계라면 홈페이지 개발 가이드에서 공개·관리자 영역의 책임도 먼저 나누십시오.
Metadata API에서 놓치기 쉬운 병합 규칙#
| 항목 | 권장 방식 | 검수 질문 |
|---|---|---|
| title·description | 페이지마다 고유 생성 | 실제 본문 질문과 같은가 |
| canonical | 대표 공개 URL 하나 지정 | 쿼리·별칭 URL과 충돌하지 않는가 |
| openGraph | 공통 필드를 공유 객체로 재사용 | 하위 객체가 siteName·image를 지우지 않았는가 |
| robots | 공개 상태와 함께 결정 | 비공개 문서가 sitemap에 남지 않는가 |
| image | 실제 접근 가능한 절대 URL 검증 | 배포 환경에서도 200인가 |
Next.js 15 공식 문서에 따르면 정적 값은 metadata, 경로별 값은 generateMetadata로 만들 수 있습니다. 또 같은 세그먼트의 중첩 metadata는 깊게 합쳐지지 않습니다. 예를 들어 자식이 openGraph를 새로 정의하면 부모의 같은 객체 필드는 상속된다고 가정하지 말고 빌드된 HTML을 확인해야 합니다.
시나리오: 글 한 편을 수정발행할 때#
- slug는 유지하고 제목, 설명, 본문, 수정일을 같은 레코드에서 갱신합니다.
- 서버 응답 HTML에 H1, 첫 답변, 핵심 표와 내부 링크가 있는지 확인합니다.
- canonical이 현재 공개 URL을 가리키고 중복 URL은 같은 대표 주소를 가리키게 합니다.
- sitemap의 lastmod가 실제 수정일을 반영하는지 확인합니다.
- 구조화 데이터가 보이는 제목, FAQ, 날짜와 같은 값을 담는지 검사합니다.
- 배포 뒤 공개 URL, OG 이미지, 연결된 내부 링크가 모두 200인지 점검합니다.
클라이언트에서 뒤늦게 제목이나 canonical을 바꾸는 방식에 기대지 마십시오. Google의 JavaScript SEO 공식 문서도 고유한 title과 description, canonical, 구조화 데이터를 검색엔진이 처리할 수 있는 형태로 제공하도록 안내합니다. 중요한 답과 링크는 초기 HTML에서 확인할 수 있게 두는 편이 진단하기 쉽습니다.
네 가지 색인 신호를 한 표로 대조하십시오#
| 신호 | 역할 | 서로 맞아야 할 값 | 검증 |
|---|---|---|---|
| HTTP 응답 | 접근 가능 여부 | 공개·삭제 상태 | 200·리다이렉트·404 확인 |
| canonical | 대표 URL 제안 | slug·도메인·프로토콜 | HTML source 검사 |
| sitemap | 발견 가능한 URL 목록 | 공개 URL·수정일 | XML과 DB 대조 |
| JSON-LD | 문서 의미 설명 | 보이는 제목·FAQ·날짜 | 문법과 본문 일치 확인 |
sitemap은 색인을 보장하는 목록이 아니며 canonical도 명령이 아니라 신호로 이해해야 합니다. 콘텐츠 발행 구조를 설계할 때는 웹사이트 속도 최적화 가이드의 응답·렌더링 점검도 함께 수행하십시오. 내부 링크는 실제 공개 중인 경로만 사용하고 링크 대상의 변경 상태까지 발행 검사에 포함해야 합니다.
배포 전 인수 체크리스트#
- 서로 다른 두 상세 URL의 title, description, canonical이 실제로 다릅니다.
- JavaScript를 실행하지 않은 HTML에도 핵심 답과 문맥형 내부 링크가 있습니다.
- openGraph의 제목, 설명, siteName, 이미지가 하위 라우트에서도 남습니다.
- 비공개 전환한 URL은 목록과 sitemap에서 빠지고 정한 응답 정책을 따릅니다.
- FAQ JSON-LD의 질문과 답은 페이지에서 사용자가 읽을 수 있습니다.
- 수정발행 뒤 sitemap lastmod와 화면의 수정일이 같은 날짜를 가리킵니다.
근거와 적용 범위#
B 외부 1차 근거로 Next.js의 Metadata 공식 문서와 프로덕션 체크리스트, Google Search Central의 JavaScript SEO 기본 가이드와 sitemap 가이드를 2026년 8월 30일 확인했습니다. 표의 배포 순서와 인수 기준은 D 운영 가설이며 사이트의 렌더링·캐시 정책에 맞춰 조정해야 합니다.
핵심 요약
- ✓App Router 사용 여부보다 URL·본문·메타·sitemap의 데이터 일치가 먼저다
- ✓중첩 metadata는 얕게 병합되므로 openGraph 공통 필드 소실을 검사한다
- ✓중요한 답과 링크는 서버 응답 HTML에서 확인할 수 있게 둔다
- ✓canonical·sitemap·JSON-LD는 보이는 페이지와 같은 공개 상태를 따라야 한다
- ✓수정발행 한 건을 끝까지 검증한 뒤 같은 계약으로 글 수를 늘린다
자주 묻는 질문