Next.js SEO 현장 점검 체크리스트: metadata API, SSR, Image 순서

이 글은 Next.js SEO 완전 가이드: App Router metadata부터 배포 확인까지의 세부 항목입니다. 전체 설정 흐름과 관련 오류 해결 순서는 대표 허브 글에서 함께 확인할 수 있습니다.

metadata와 SEO 글이 따로 있으면 문제 상황에서 무엇부터 확인해야 하는지 판단하기 어렵습니다.

이 글에서 확인할 내용

아래 섹션 링크를 통해 필요한 내용을 바로 확인할 수 있습니다.

이 글은 실무 점검 순서용 글입니다
SEO 문제는 먼저 증상을 나눠야 합니다
metadata API는 위치와 동적 값부터 확인합니다
SSR과 검색 노출은 HTML에 무엇이 담기는지의 문제입니다
Image와 OG 이미지는 별도 점검 항목입니다
점검 순서를 정해두면 수정 범위가 줄어듭니다
프로젝트에서는 페이지 하나를 끝까지 따라가며 확인합니다
마지막에는 독자가 바로 적용할 기준을 남깁니다
읽는 순서를 정하면 글도 덜 흩어집니다

이 글은 실무 점검 순서용 글입니다

이 글은 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에서는 Server Component인 layout.tsx나 page.tsx에서 metadata를 정의하거나 generateMetadata를 사용할 수 있습니다. 같은 route segment에서 정적 metadata와 generateMetadata를 동시에 export할 수는 없습니다. 정적 페이지라면 metadata 객체로 충분하지만, 게시글 상세처럼 slug마다 제목과 설명이 달라져야 한다면 generateMetadata에서 데이터를 읽어와야 합니다. 이때 같은 title이 모든 페이지에 들어가거나 description이 기본값으로 남아 있으면 검색 결과가 흐려집니다. 구조가 헷갈리면 Next.js metadata API를 먼저 확인하는 것이 좋습니다.

export async function generateMetadata({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);

  return {
    title: post.title,
    description: post.summary,
  };
}

SSR과 검색 노출은 HTML에 무엇이 담기는지의 문제입니다

검색 엔진이 페이지를 볼 때 중요한 정보가 초기 HTML에 충분히 들어가는지 확인해야 합니다. 클라이언트에서만 데이터를 가져와 화면을 채우면 검색 노출이 기대와 다를 수 있습니다. Next.js에서는 서버 컴포넌트와 데이터 요청 흐름을 함께 보면서 상세 페이지의 제목, 본문 요약, 주요 콘텐츠가 어디에서 만들어지는지 확인합니다. 검색 노출과 렌더링 관계는 Next.js SEO SSR 적용법으로 이어서 보면 됩니다.

Image와 OG 이미지는 별도 점검 항목입니다

본문 이미지가 보이는 것과 소셜·메신저 공유 미리보기 이미지가 제대로 보이는 것은 다른 문제입니다. 외부 이미지를 next/image의 원격 src로 쓰면 next.config.js의 images.remotePatterns 설정이 필요할 수 있습니다. 반면 OG 이미지는 metadata의 openGraph.images, metadataBase, 또는 opengraph-image 파일 규칙과 연결됩니다. 이미지가 개발 환경에서는 보이는데 배포 후 깨진다면 도메인, 경로, 캐시를 차례대로 봐야 합니다.

공식 문서 기준으로 Next.js Metadata API는 SEO와 공유 미리보기를 위한 metadata를 정의하고, generateMetadata는 App Router route segment에서 동적 metadata를 만들 때 사용합니다. remotePatterns는 next/image 원격 이미지 허용 범위이고, OG 이미지는 Metadata API나 opengraph-image 파일 규칙으로 따로 다룹니다. 자세한 기준은 generateMetadata 문서, Metadata and OG images 문서, Image remotePatterns 문서, opengraph-image 문서를 함께 확인하면 좋습니다.

점검 순서를 정해두면 수정 범위가 줄어듭니다

추천 순서는 title과 description 확인, metadata 적용 여부 확인, 동적 페이지 데이터 로딩 확인, 초기 HTML에 핵심 콘텐츠가 있는지 확인, Image/OG 설정 확인입니다. 모든 문제를 한 번에 고치려 하면 원인을 놓치기 쉽습니다. metadata가 적용되지 않는 문제는 별도 체크리스트로, Image 오류는 이미지 설정 글로 분리해 보는 것이 좋습니다.

프로젝트에서는 페이지 하나를 끝까지 따라가며 확인합니다

Next.js를 공부할 때 개념을 따로따로 보면, metadata, Image 설정이 별개의 주제처럼 보입니다. 하지만 실제 프로젝트에서는 페이지 하나가 이 개념을 모두 지나갑니다. 예를 들어 블로그 상세 페이지라면 URL이 slug와 연결되고, 서버에서 글 데이터를 읽고, title과 description을 만들고, 대표 이미지를 설정한 뒤 배포 환경에서 제대로 보이는지 확인해야 합니다.

그래서 학습이나 점검은 페이지 단위로 하는 것이 좋습니다. 먼저 URL을 입력했을 때 어떤 page.tsx가 실행되는지 확인합니다. 그 다음 데이터 요청 위치, metadata 생성 위치, 이미지 도메인 설정, redirects나 not-found 처리까지 이어서 봅니다. 이 순서를 따르면 문제가 생겼을 때 “SEO가 안 된다”처럼 크게 말하지 않고, title 문제인지 렌더링 문제인지 이미지 문제인지 좁혀갈 수 있습니다.

배포 전에는 로컬 화면만 믿지 않는 것이 좋습니다. 정적 생성 페이지라면 빌드 산출물 HTML을 확인하고, SSR이나 동적 렌더링 페이지라면 next start 또는 실제 배포 URL의 응답 HTML에 필요한 내용이 들어갔는지 확인합니다. 공유 미리보기에서 OG 이미지가 보이는지, 외부 이미지 도메인이 허용되어 있는지도 함께 봐야 합니다. 작은 체크리스트를 만들어두면 다음 프로젝트에서도 같은 실수를 줄일 수 있습니다.

마지막에는 독자가 바로 적용할 기준을 남깁니다

Next.js SEO를 점검할 때는 먼저 문제가 title인지, description인지, 초기 HTML인지, OG 이미지인지 나눕니다. 증상을 나누면 metadata API, 렌더링 방식, Image 설정 중 어디를 봐야 하는지 바로 정할 수 있습니다.

layout.tsx나 page.tsx의 metadata가 실제 페이지에 적용되는가?
동적 상세 페이지는 generateMetadata에서 slug별 title과 description을 만드는가?
검색에 필요한 본문 요약과 주요 콘텐츠가 초기 HTML에 들어가는가?
OG 이미지 경로, 외부 이미지 도메인, 캐시 문제가 없는가?
로컬 화면뿐 아니라 빌드 후 HTML과 공유 미리보기까지 확인했는가?

읽는 순서를 정하면 글도 덜 흩어집니다

Next.js SEO 체크리스트의 핵심은 metadata, SSR/초기 HTML, Image/OG, 배포 후 확인을 순서대로 나누는 것입니다. 이렇게 보면 SEO 문제를 한 번에 뭉뚱그리지 않고 어디부터 고쳐야 하는지 빠르게 좁힐 수 있습니다.