이 글은 Next.js SEO 완전 가이드: App Router metadata부터 배포 확인까지의 세부 항목입니다. 전체 설정 흐름과 관련 오류 해결 순서는 대표 허브 글에서 함께 확인할 수 있습니다.
metadata와 SEO 글이 따로 있으면 문제 상황에서 무엇부터 확인해야 하는지 판단하기 어렵습니다.
이 글은 실무 점검 순서용 글입니다
이 글은 metadata 문법을 처음부터 다시 설명하는 대표 글이 아니라, 실제 프로젝트에서 SEO 문제가 보일 때 확인 순서를 정하는 체크리스트입니다. metadata의 설계 기준은 Next.js App Router metadata 설정 기준을 먼저 보고, 코드 예제는 Next.js Metadata API 실무 예제에서 확인하면 됩니다.
SEO 문제는 먼저 증상을 나눠야 합니다
Next.js에서 SEO가 안 된다고 느낄 때 원인은 하나가 아닙니다. 검색 결과의 title이 이상한 경우, description이 비어 있는 경우, OG 이미지가 보이지 않는 경우, 동적 상세 페이지가 검색에 약한 경우가 서로 다릅니다. 그래서 바로 코드를 고치기보다 증상을 먼저 나눠야 합니다. title과 description 문제라면 metadata API, 검색 노출과 HTML 구조 문제라면 렌더링 방식, 이미지 미리보기 문제라면 Image와 OG 설정을 봅니다.
metadata API는 위치와 동적 값부터 확인합니다
App Router에서는 layout.tsx나 page.tsx에서 metadata를 정의하거나 generateMetadata를 사용할 수 있습니다. 정적 페이지라면 metadata 객체로 충분하지만, 게시글 상세처럼 slug마다 제목과 설명이 달라져야 한다면 에서 데이터를 읽어와야 합니다. 이때 같은 title이 모든 페이지에 들어가거나 description이 기본값으로 남아 있으면 검색 결과가 흐려집니다. 구조가 헷갈리면 Next.js metadata API를 먼저 확인하는 것이 좋습니다.
export async function generateMetadata({ params }) { const post = await getPost(params.slug); return { title: post.title, description: post.summary};
}SSR과 검색 노출은 HTML에 무엇이 담기는지의 문제입니다
검색 엔진이 페이지를 볼 때 중요한 정보가 초기 HTML에 충분히 들어가는지 확인해야 합니다. 클라이언트에서만 데이터를 가져와 화면을 채우면 검색 노출이 기대와 다를 수 있습니다. Next.js에서는 서버 컴포넌트와 데이터 요청 흐름을 함께 보면서 상세 페이지의 제목, 본문 요약, 주요 콘텐츠가 어디에서 만들어지는지 확인합니다. 검색 노출과 렌더링 관계는 Next.js SEO SSR 적용법으로 이어서 보면 됩니다.
Image와 OG 이미지는 별도 점검 항목입니다
본문 이미지가 보이는 것과 검색·공유 미리보기 이미지가 제대로 보이는 것은 다른 문제입니다. 외부 이미지 도메인을 쓰면 next.config 설정이 필요할 수 있고, OG 이미지는 metadata의 openGraph 설정이나 별도 이미지 생성 구조와 연결됩니다. 이미지가 개발 환경에서는 보이는데 배포 후 깨진다면 도메인, 경로, 캐시를 차례대로 봐야 합니다.
점검 순서를 정해두면 수정 범위가 줄어듭니다
추천 순서는 title과 description 확인, 적용 여부 확인, 동적 페이지 데이터 로딩 확인, 초기 HTML에 핵심 콘텐츠가 있는지 확인, Image/OG 설정 확인입니다. 모든 문제를 한 번에 고치려 하면 원인을 놓치기 쉽습니다. metadata가 적용되지 않는 문제는 별도 체크리스트로, Image 오류는 이미지 설정 글로 분리해 보는 것이 좋습니다.
프로젝트에서는 페이지 하나를 끝까지 따라가며 확인합니다
Next.js를 공부할 때 개념을 따로따로 보면, metadata, Image 설정이 별개의 주제처럼 보입니다. 하지만 실제 프로젝트에서는 페이지 하나가 이 개념을 모두 지나갑니다. 예를 들어 블로그 상세 페이지라면 URL이 slug와 연결되고, 서버에서 글 데이터를 읽고, title과 description을 만들고, 대표 이미지를 설정한 뒤 배포 환경에서 제대로 보이는지 확인해야 합니다.
그래서 학습이나 점검은 페이지 단위로 하는 것이 좋습니다. 먼저 URL을 입력했을 때 어떤 가 실행되는지 확인합니다. 그 다음 데이터 요청 위치, metadata 생성 위치이미지 도메인 설정, redirects나 not-found 처리까지 이어서 봅니다. 이 순서를 따르면 문제가 생겼을 때 “SEO가 안 된다”처럼 크게 말하지 않고, title 문제인지 렌더링 문제인지 이미지 문제인지 좁혀갈 수 있습니다.
배포 전에는 로컬 화면만 믿지 않는 것이 좋습니다. 실제 빌드 후 HTML에 필요한 내용이 들어갔는지, 공유 미리보기에서 OG 이미지가 보이는지, 외부 이미지 도메인이 허용되어 있는지 확인해야 합니다. 작은 체크리스트를 만들어두면 다음 프로젝트에서도 같은 실수를 줄일 수 있습니다.
마지막에는 독자가 바로 적용할 기준을 남깁니다
Next.js SEO 체크리스트: metadata API, Image까지 점검하기을 읽는 독자는 단순한 정의보다 “그래서 지금 내 코드에서는 무엇을 먼저 확인해야 하는가”를 알고 싶어 합니다. 그래서 글을 작성할 때는 개념을 설명한 뒤 바로 판단 질문으로 이어지는 흐름이 필요합니다. 이 값은 어디에서 만들어졌는지, 어느 컴포넌트나 페이지가 책임지는지, 배포나 빌드 뒤에도 같은 방식으로 동작하는지처럼 실제 작업에서 바로 확인할 수 있는 질문을 남겨야 합니다.
또 하나 중요한 기준은 기존 글과의 거리입니다. 이미 자세히 다룬 문법이나 오류 해결 절차를 다시 길게 반복하면 새 글의 역할이 흐려집니다. 이 글은 독자가 흩어진 글을 어떤 순서로 읽을지 알려주는 입구이거나, 서로 다른 개념을 연결하는 브릿지여야 합니다. 세부 구현은 관련 글로 넘기고, 현재 글에서는 왜 그 글을 그 시점에 읽어야 하는지 설명하는 것이 더 좋습니다.
실제 작성 과정에서는 예시를 하나 정해 끝까지 밀고 가는 편이 자연스럽습니다. 카드 UI, 블로그 상세 페이지, 장바구니 상태, 코딩테스트 입력 배열처럼 작은 상황 하나를 잡고 설명하면 개념이 공중에 뜨지 않습니다. 독자가 자신의 코드에 대입할 수 있는 기준이 생기면, 글은 단순 요약이 아니라 다음 작업을 결정하는 안내문 역할을 하게 됩니다.
마지막 정리는 “무엇을 외울 것인가”보다 “무엇부터 확인할 것인가”로 끝내는 것이 좋습니다. 처음 볼 파일, 먼저 나눌 상태, 우선 점검할 설정, 다음에 읽을 기존 글을 짧게 안내하면 독자가 바로 움직일 수 있습니다. 이런 마무리가 있어야 허브 글과 브릿지 글이 기존 글을 반복하지 않고도 충분한 가치를 가집니다.
읽는 순서를 정하면 글도 덜 흩어집니다
Next.js SEO 체크리스트: metadata API, Image까지 점검하기의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.
“Next.js SEO 현장 점검 체크리스트: metadata API, SSR, Image 순서”에 대한 1개의 생각