Next.js App Router SEO 가이드: 랜딩·SaaS 사이트 검색 노출을 놓치지 않는 구조
결론부터 말하면, Next.js App Router SEO는 메타태그 몇 줄을 추가하는 작업이 아닙니다. 랜딩 페이지, 가격 페이지, 블로그, 고객 사례처럼 검색 노출이 필요한 화면은 서버에서 제목·설명·본문·내부 링크·구조화 데이터가 읽히도록 만들고, 로그인 이후 SaaS 대시보드와 관리자 화면은 색인보다 인증·데이터 최신성·사용성에 맞춰 분리해야 합니다. App Router에서는 Metadata API, React Server Components, sitemap.ts, robots.ts, 캐싱, Core Web Vitals가 한 덩어리로 설계됩니다. 작성 기준은 2026년 6월 10일입니다.
1. App Router SEO에서 가장 자주 생기는 오해
대표나 마케터 입장에서는 Next.js 사이트가 빠르게 보이면 SEO도 잘 되어 있다고 느끼기 쉽습니다. 하지만 검색엔진이 보는 것은 디자인 완성도가 아니라 HTTP 응답, 초기 HTML, 링크 구조, canonical, robots 지시, 구조화 데이터, 페이지 성능입니다. Google은 JavaScript를 렌더링할 수 있지만, 서버 렌더링 또는 사전 렌더링은 사용자와 크롤러 모두에게 여전히 유리하며 모든 봇이 JavaScript를 실행하는 것도 아닙니다. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?rd=1&visit_id=638120923109115860-3890602092))
Pages Router 시절의 next/head, getStaticProps, getServerSideProps 중심 사고를 그대로 가져오면 App Router의 장점을 놓칩니다. App Router에서는 app/layout.tsx, app/page.tsx, generateMetadata, 서버 컴포넌트, 라우트 그룹, 특수 메타데이터 파일이 SEO의 기본 단위가 됩니다. 특히 metadata와 generateMetadata는 서버 컴포넌트에서 지원되고, 정적 메타데이터는 초기 HTML에 포함될 수 있도록 설계해야 합니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/functions/generate-metadata))
실무 기준: 검색 노출이 필요한 페이지의 핵심 정보가
useEffect실행 후에만 나타난다면 먼저 의심해야 합니다. 사용자는 볼 수 있어도 크롤링·렌더링·색인 과정에서는 지연, 누락, 중복 판단이 생길 수 있습니다.
2. 랜딩·SaaS 사이트는 먼저 페이지 성격을 나눠야 한다
Next.js SEO 설계의 첫 단계는 기술 선택이 아니라 URL의 목적 분류입니다. 같은 코드베이스 안에서도 공개 랜딩, 콘텐츠, SaaS 앱, 관리자 화면은 운영 기준이 다릅니다. App Router의 라우트 그룹은 폴더명을 URL에 노출하지 않고 관심사별로 라우트를 나눌 수 있어 이런 분리에 적합합니다. 단, 서로 다른 루트 레이아웃 사이 이동은 전체 페이지 로드가 발생할 수 있으므로 사용자 흐름을 고려해야 합니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/file-conventions/route-groups))
| 영역 | 예시 URL | SEO 목표 | 권장 렌더링 | 운영 주의 |
|---|---|---|---|---|
| 마케팅 랜딩 | /, /features, /pricing | 브랜드·기능·가격 검색 노출 | 정적 생성 또는 캐시 가능한 서버 렌더링 | 타이틀·설명·CTA·내부 링크를 HTML에 포함 |
| 콘텐츠 | /blog/[slug], /case/[slug] | 롱테일 키워드와 문제 해결형 유입 | 정적 생성, ISR, 명시적 캐시 | slug별 metadata, canonical, lastModified 관리 |
| 문서·가이드 | /docs/[...slug] | 제품 이해와 기술 검토 단계 유입 | 서버 렌더링 또는 정적 생성 | 목차, breadcrumb, 버전 표시 필요 |
| SaaS 대시보드 | /app, /workspace | 검색 노출보다 업무 UX | 인증 기반 동적 렌더링 | noindex, 인증, 데이터 최신성 우선 |
| 관리자 화면 | /admin | 색인 금지 | 동적 렌더링 | robots 차단만 믿지 말고 인증과 noindex 병행 |
실무 폴더 구조는 다음처럼 시작할 수 있습니다.
app/(marketing)/page.tsx
app/(marketing)/pricing/page.tsx
app/(content)/blog/[slug]/page.tsx
app/(content)/case/[slug]/page.tsx
app/(app)/workspace/page.tsx
app/(admin)/admin/page.tsx
app/sitemap.ts
app/robots.tsAgentMit이 정부지원 MVP나 SaaS 소개 사이트를 설계할 때도 이 분류를 먼저 잡습니다. 공개 랜딩은 검색과 전환을 위해 가볍고 읽히게 만들고, BizMit 같은 업무 운영·관리 화면은 인증, 권한, 데이터 처리, 관리자 생산성을 중심으로 분리하는 방식입니다.
3. Metadata API: 고정 페이지와 동적 페이지를 다르게 설계한다
App Router에서는 정적 페이지라면 metadata 객체를, slug나 외부 데이터에 따라 제목·설명이 달라지는 페이지라면 generateMetadata를 사용합니다. 같은 라우트 세그먼트에서 둘을 동시에 export할 수 없고, 파일 기반 메타데이터가 코드 기반 metadata보다 우선할 수 있으므로 OG 이미지와 아이콘 파일의 위치도 함께 관리해야 합니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/functions/generate-metadata))
| 항목 | 실무 기준 | 주의할 점 |
|---|---|---|
| title | 페이지별 검색 의도와 브랜드명을 함께 반영 | 모든 페이지가 같은 제목이면 검색 결과에서 구분이 어렵다 |
| description | 사용자가 클릭 전 얻을 수 있는 구체적 약속 작성 | 키워드 나열보다 문제·대상·결과를 압축한다 |
| canonical | 동일 콘텐츠의 대표 URL을 명확히 지정 | 쿼리 파라미터, UTM, 필터 페이지 중복을 방치하지 않는다 |
| openGraph/twitter | 공유 이미지, 제목, 설명을 페이지 성격에 맞춤 | 블로그·사례 페이지는 기본 이미지 하나로 끝내지 않는다 |
| robots | 공개 페이지는 index, 내부 화면은 noindex | 스테이징, 관리자, 검색 결과 페이지가 노출되지 않게 한다 |
| alternates | 다국어·지역 페이지가 있으면 hreflang 전략 수립 | 번역 품질과 URL 구조가 정리되지 않았다면 성급히 늘리지 않는다 |
import type { Metadata } from 'next'
export const metadata: Metadata = {
title: {
default: 'B2B SaaS 업무 자동화',
template: '%s | B2B SaaS 업무 자동화'
},
description: '영업, 운영, 관리자 업무를 한곳에서 관리하는 SaaS입니다.',
metadataBase: new URL('https://example.com'),
alternates: { canonical: '/' },
openGraph: {
type: 'website',
title: 'B2B SaaS 업무 자동화',
description: '반복 업무와 관리자 운영을 줄이는 SaaS 소개 페이지'
},
robots: { index: true, follow: true }
}동적 콘텐츠에서는 generateMetadata가 유용하지만, 외부 API가 느리거나 요청마다 값이 달라지면 초기 HTML과 캐싱 전략이 흔들릴 수 있습니다. 블로그·사례·제품 상세처럼 검색 노출이 중요한 페이지라면 CMS나 관리자에서 발행 상태, 제목, 설명, 대표 이미지, lastModified를 안정적으로 저장하고, 메타데이터 생성도 그 데이터에 맞춰 결정하는 편이 좋습니다.
4. Next.js 15 이후 캐싱 변화는 SEO 운영에도 영향을 준다
Next.js 15에서는 서버 사이드 fetch 요청과 GET Route Handler의 캐싱 기본값이 바뀌었고, 필요하면 cache: 'force-cache', fetchCache, dynamic = 'force-static' 같은 설정으로 명시해야 합니다. Next.js 16은 Cache Components와 'use cache' 방향을 제시하며 캐싱을 더 명시적으로 다루게 했습니다. 검색 노출 페이지에서는 이 변화가 중요합니다. 콘텐츠가 너무 자주 동적으로 처리되면 성능과 안정성이 떨어지고, 반대로 오래 캐시되면 발행·수정 내용이 검색엔진에 늦게 반영될 수 있습니다. ([nextjs.org](https://nextjs.org/docs/app/guides/upgrading/version-15))
| 상황 | 권장 판단 | 예시 |
|---|---|---|
| 회사 소개·기능 소개 | 강한 캐시 또는 정적 생성 | 릴리스 때만 변경 |
| 가격 페이지 | 가격 변경 프로세스와 캐시 무효화 연결 | 관리자 수정 후 재검증 |
| 블로그·뉴스 | 발행 시점 기반 revalidate 또는 온디맨드 무효화 | 수정일을 sitemap lastModified에 반영 |
| 로그인 대시보드 | 요청 시점 데이터 우선 | SEO보다 최신 데이터·권한 |
비개발자가 확인할 질문은 단순합니다. “이 페이지는 검색 결과에 노출되어야 하는가?”, “수정 후 몇 분 또는 몇 시간 안에 반영되어야 하는가?”, “관리자에서 비공개로 바꾼 글이 sitemap에 남지 않는가?” 이 세 가지 질문에 답하지 못하면 캐싱 설계가 아직 운영 수준에 도달하지 않은 것입니다.
5. sitemap.ts와 robots.ts는 자동화하되, 무조건 자동으로 만들면 안 된다
App Router에서는 app/sitemap.ts로 사이트맵을 코드로 생성할 수 있고, app/robots.ts로 robots.txt를 생성할 수 있습니다. Next.js 문서 기준으로 sitemap과 robots는 특수 Route Handler이며, 요청 시간 API나 동적 설정을 사용하지 않으면 기본적으로 캐시될 수 있습니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap))
문제는 파일을 만드는 것이 아니라 “무엇을 넣고 무엇을 빼는가”입니다. SaaS 소개 사이트에서 사이트맵에 들어가야 하는 것은 공개 랜딩, 기능 페이지, 가격 페이지, 발행된 블로그, 공개 고객 사례입니다. 들어가면 안 되는 것은 로그인 페이지 뒤의 대시보드, 관리자, 미리보기 URL, 검색 결과 필터 URL, 비공개 글, 삭제 예정 캠페인 페이지입니다.
| 체크 항목 | 질문 | 권장 처리 |
|---|---|---|
| 발행 상태 | draft, private, archived가 sitemap에 들어가나? | published만 포함 |
| 수정일 | 모든 URL의 lastModified가 현재 시간으로 찍히나? | 실제 콘텐츠 수정일 사용 |
| canonical | sitemap URL과 canonical URL이 같은가? | 한쪽으로 통일 |
| 다국어 | 한국어·영어 URL이 서로 연결되어 있나? | alternates와 URL 정책 정리 |
| 관리자 | /admin, /app이 sitemap에 들어가나? | 제외, 인증, noindex 적용 |
robots.txt는 크롤러 접근을 제어하는 파일이지 색인 제거를 보장하는 장치가 아닙니다. Google 문서도 robots meta tag와 X-Robots-Tag가 페이지 단위 색인·스니펫 제어에 쓰인다고 설명합니다. 색인을 원하지 않는 HTML 페이지라면 페이지가 크롤링 가능한 상태에서 noindex를 확인할 수 있어야 하고, 인증이 필요한 정보는 애초에 공개 응답으로 노출하지 않아야 합니다. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag))
6. 서버 컴포넌트와 클라이언트 컴포넌트의 경계가 SEO 품질을 좌우한다
Next.js App Router의 레이아웃과 페이지는 기본적으로 서버 컴포넌트입니다. 서버 컴포넌트는 데이터 접근, 비밀키 보호, 브라우저로 보내는 JavaScript 감소, 초기 콘텐츠 표시 측면에서 유리합니다. 반면 상태, 이벤트 핸들러, 브라우저 API, 복잡한 인터랙션은 클라이언트 컴포넌트가 필요합니다. ([nextjs.org](https://nextjs.org/docs/app/getting-started/server-and-client-components))
SEO 페이지에서의 원칙은 “핵심 콘텐츠는 서버, 상호작용은 클라이언트”입니다. 예를 들어 가격표의 요금제 이름, 핵심 기능, FAQ 질문, 고객 사례 요약은 서버에서 렌더링하고, 월간·연간 토글, 계산기, 데모 모달, 필터 UI만 클라이언트 컴포넌트로 분리합니다.
| 요소 | 서버 렌더링 권장 | 클라이언트 컴포넌트 권장 |
|---|---|---|
| 랜딩 H1·본문 | 예 | 아니오 |
| 가격표 핵심 정보 | 예 | 토글 UI만 가능 |
| 블로그 본문 | 예 | 댓글·좋아요 등 부가 기능 |
| 대시보드 차트 | 초기 요약 가능 | 상호작용 차트는 가능 |
| 관리자 편집기 | SEO 불필요 | 예 |
많은 SaaS 랜딩에서 실수하는 지점은 “디자인 시스템 전체를 클라이언트 컴포넌트로 감싸는 것”입니다. 테마, 토스트, 모달, 분석 스크립트 때문에 루트 전체를 'use client'로 만들면 검색 대상 페이지의 장점이 줄어듭니다. provider는 가능한 깊게 배치하고, 검색엔진이 읽어야 하는 텍스트와 링크는 서버 영역에 남겨두는 것이 안전합니다.
7. 구조화 데이터는 ‘순위 부스터’가 아니라 의미 설명서다
구조화 데이터는 검색엔진에 페이지의 의미를 명시적으로 설명하는 형식입니다. Google은 대부분의 Search 구조화 데이터에서 schema.org 어휘를 사용하지만, Google Search에서 어떤 속성이 의미 있는지는 Google Search Central 문서를 기준으로 봐야 합니다. 또한 구조화 데이터가 올바르다고 해서 리치 결과 노출이 보장되지는 않으며, 본문에 보이지 않는 정보를 마크업하면 품질 문제로 이어질 수 있습니다. ([developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data))
B2B SaaS 사이트에서 현실적으로 검토할 수 있는 구조화 데이터는 다음과 같습니다.
| 타입 | 적합한 페이지 | 주의 |
|---|---|---|
| Organization | 회사 소개, 전체 사이트 공통 | 상호, 로고, 연락처, sameAs를 실제 정보와 일치 |
| WebSite | 홈 | 사이트명과 검색 대상 범위가 명확할 때 사용 |
| BreadcrumbList | 블로그, 문서, 사례 | 화면에 보이는 경로와 일치 |
| Article 또는 BlogPosting | 콘텐츠 게시글 | 작성일, 수정일, 작성자, 대표 이미지 관리 |
| SoftwareApplication | SaaS 제품 소개 | 가격, 평점, 운영체제 등을 무리하게 꾸미지 않기 |
FAQ는 더 조심해야 합니다. 2026년 5월 7일 기준 Google은 FAQ 리치 결과가 검색 결과에 더 이상 나타나지 않는다고 공지했고, 관련 지원도 단계적으로 제거 중입니다. 또한 FAQPage 리치 결과는 잘 알려진 정부·건강 분야 권위 사이트 중심으로 제한되어 있습니다. 따라서 일반 B2B SaaS는 FAQ 구조화 데이터로 검색 결과 장식 효과를 기대하기보다, 실제 구매 검토자가 묻는 질문을 본문에 명확히 답하는 데 집중하는 편이 낫습니다. ([developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/faqpage))
8. Core Web Vitals: 기술 SEO의 숫자 기준
Core Web Vitals는 LCP, INP, CLS를 중심으로 실제 사용자 경험을 평가합니다. web.dev 기준으로 좋은 상태는 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하이며, 페이지 또는 사이트 판단에는 75번째 백분위수 값이 사용됩니다. ([web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en))
| 지표 | 의미 | Good 기준 | Next.js 실무 개선 포인트 |
|---|---|---|---|
| LCP | 주요 콘텐츠가 보이는 속도 | 2.5초 이하 | 히어로 이미지 최적화, 서버 응답, 폰트, 불필요한 JS 제거 |
| INP | 사용자 입력 반응성 | 200ms 이하 | 무거운 클라이언트 컴포넌트 분리, 서드파티 스크립트 지연 |
| CLS | 예상치 못한 레이아웃 이동 | 0.1 이하 | 이미지 width/height, 광고·배너 공간 예약, 폰트 로딩 관리 |
Next.js Image Component는 이미지 최적화에 유용하지만, 설정 없이 모든 문제가 해결되지는 않습니다. Next.js 16에서는 priority가 preload 방향으로 정리되었고, LCP 이미지라면 preload, eager, fetchPriority 중 무엇을 쓸지 상황별로 판단해야 합니다. 원격 이미지는 width와 height를 지정해 비율을 알 수 있게 해야 레이아웃 이동을 줄일 수 있습니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/components/image))
성능 점검은 Lighthouse 점수 하나로 끝내면 안 됩니다. 배포 이후 실제 사용자 환경에서 문제가 생기는지 보려면 프론트엔드 성능, 서버 응답, API 오류, 배포 버전, 외부 스크립트 장애를 함께 봐야 합니다. 작은 팀의 관측성 설계는 OpenTelemetry 관측성 가이드에서 다룬 것처럼 최소한의 추적부터 시작하는 편이 현실적입니다.
9. 배포 전 Next.js App Router SEO 체크리스트
기획·콘텐츠 체크
- 각 공개 페이지의 주 검색 의도와 타깃 독자가 정리되어 있는가?
- H1이 페이지마다 고유하고, title과 같은 방향을 바라보는가?
- 가격, 기능, 도입 효과, 대상 고객이 이미지 안 텍스트가 아니라 HTML 텍스트로 존재하는가?
- 블로그와 사례 글의 작성일, 수정일, 작성자, 카테고리가 운영 데이터로 관리되는가?
- 비공개, 임시, 스테이징 URL이 내부 링크나 sitemap에 포함되지 않는가?
개발 체크
metadata와generateMetadata가 페이지 성격에 맞게 쓰였는가?- 검색 대상 페이지의 핵심 본문이 서버에서 렌더링되는가?
app/sitemap.ts가 공개·발행 URL만 반환하는가?app/robots.ts가 관리자와 내부 화면 정책을 반영하는가?- canonical, OG, Twitter, favicon, app icon, 대표 이미지가 실제 URL에서 확인되는가?
- 404, redirect, notFound 처리 시 잘못된 200 응답을 내지 않는가?
- 구조화 데이터가 본문과 일치하고 Rich Results Test 또는 URL Inspection에서 확인되는가?
운영 체크
- 콘텐츠 발행·수정·비공개 처리와 캐시 무효화가 연결되어 있는가?
- Search Console에서 sitemap 제출 후 색인 제외 사유를 확인하는 담당자가 있는가?
- 가격 변경, 리브랜딩, 도메인 변경 시 canonical과 metadata를 함께 점검하는가?
- 서드파티 태그 추가 전후로 LCP, INP, CLS 변화를 비교하는가?
- 관리자에서 삭제한 콘텐츠가 sitemap, 내부 링크, 추천 글 위젯에 남지 않는가?
10. PM·마케터가 직접 할 수 있는 5분 진단
- 브라우저에서 페이지 소스 보기를 열고 H1, 주요 문장, 가격표 텍스트가 있는지 확인합니다.
- Search Console URL 검사에서 Google이 본 HTML과 색인 가능 여부를 확인합니다.
- PageSpeed Insights에서 모바일 기준 LCP 요소가 무엇인지 봅니다.
- 공유 디버거 또는 미리보기 도구로 OG 제목·이미지가 페이지별로 다른지 확인합니다.
- /sitemap.xml과 /robots.txt를 직접 열어 공개해야 할 URL과 숨겨야 할 URL을 대조합니다.
이 5가지만 해도 “Next.js로 만들었는데 왜 검색에 안 나오지?”라는 문제의 상당 부분을 초기에 잡을 수 있습니다. 더 나아가 AI 에이전트로 Search Console, 배포 로그, 사이트맵 점검을 자동화하려면 권한과 감사 로그 설계가 먼저 필요합니다. 이 부분은 MCP 서버 구축 전 체크리스트의 보안 관점과도 연결됩니다.
11. AgentMit이 보는 현실적인 설계 기준
AgentMit은 Next.js SEO를 “검색엔진용 설정”으로만 보지 않습니다. 실제 프로젝트에서는 공개 랜딩, 콘텐츠 관리, SaaS 대시보드, 관리자, 결제, 알림, 자동화가 같은 제품 안에서 움직입니다. 그래서 처음부터 검색 대상 URL과 업무 대상 URL을 분리하고, 관리자에서 발행한 콘텐츠가 metadata, sitemap, 내부 링크, 캐시 무효화까지 이어지도록 설계해야 장기 운영이 가능합니다.
BizMit 기반의 업무 시스템이나 정부지원 MVP에서도 마찬가지입니다. 외부 투자자·심사위원·고객이 보는 소개 페이지는 서버 렌더링과 정적 생성 중심으로 가볍게 만들고, 로그인 이후 운영 화면은 권한과 데이터 최신성 중심으로 설계하는 편이 낫습니다. 프로젝트 구조가 이미 복잡해졌다면 BizMit 운영 구조를 참고하거나, 검색 노출이 필요한 공개 영역만 먼저 분리해 개선하는 접근도 가능합니다.
FAQ
Q1. Next.js App Router는 SEO에 불리한가요?
불리하지 않습니다. 오히려 서버 컴포넌트, Metadata API, sitemap.ts, robots.ts를 제대로 쓰면 랜딩·콘텐츠 사이트에 적합합니다. 다만 검색 대상 페이지를 클라이언트 렌더링 중심으로 만들면 장점을 잃습니다.
Q2. Next.js 랜딩 페이지는 정적 생성이 좋나요, 서버 렌더링이 좋나요?
변경이 적은 랜딩과 가격 페이지는 정적 생성 또는 명시적 캐시가 유리합니다. 요청마다 달라져야 하는 정보가 있다면 해당 부분만 동적으로 분리하고, 핵심 콘텐츠는 안정적인 HTML로 제공하는 편이 좋습니다.
Q3. generateMetadata는 모든 페이지에 써야 하나요?
아닙니다. 고정 페이지는 metadata 객체가 단순하고 안전합니다. generateMetadata는 블로그, 사례, 제품 상세처럼 URL별로 제목·설명·이미지가 달라지는 페이지에 쓰는 것이 적합합니다.
Q4. sitemap.ts를 만들었는데 왜 색인이 안 되나요?
sitemap은 URL 발견을 돕는 파일입니다. 페이지가 noindex 상태이거나, 인증이 필요하거나, canonical이 다른 URL을 가리키거나, 본문이 빈약하거나, 서버 오류가 있으면 색인이 되지 않을 수 있습니다.
Q5. 관리자 화면도 robots.txt에서 막으면 충분한가요?
충분하지 않습니다. 관리자와 대시보드는 인증, 권한, noindex, sitemap 제외를 함께 적용해야 합니다. 민감한 데이터는 robots.txt가 아니라 애초에 비인증 사용자에게 응답하지 않도록 설계해야 합니다.
참고한 공식 문서
이 글은 Next.js 공식 문서, Google Search Central, web.dev 문서를 기준으로 작성했습니다. 단, 실제 적용 시에는 사용 중인 Next.js 버전, 호스팅 플랫폼, 배포 런타임, 콘텐츠 운영 방식에 맞춰 세부 설정을 다시 확인해야 합니다.
- Next.js Metadata API와 generateMetadata 문서. ([nextjs.org](https://nextjs.org/docs/app/api-reference/functions/generate-metadata))
- Next.js sitemap.ts, robots.ts, Metadata Files 문서. ([nextjs.org](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap))
- Next.js Server and Client Components, Route Groups, Image Component 문서. ([nextjs.org](https://nextjs.org/docs/app/getting-started/server-and-client-components))
- Next.js 15 업그레이드 가이드와 Next.js 16 발표 문서. ([nextjs.org](https://nextjs.org/docs/app/guides/upgrading/version-15))
- Google JavaScript SEO, 구조화 데이터, FAQPage, robots meta 문서. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?rd=1&visit_id=638120923109115860-3890602092))
- web.dev Core Web Vitals 임계값 문서. ([web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en))
Next.js 랜딩, SaaS 소개 페이지, 관리자 대시보드, 업무 자동화 화면을 같은 제품 안에서 정리해야 한다면 AgentMit은 SEO와 운영 구조를 함께 검토합니다. 필요 시 제작 문의로 현재 URL 구조와 운영 문제를 공유해 주세요.
