Next.js 빌드가 91,000개 페이지를 컴파일합니다. 각 페이지는 JSON-LD 스키마를 포함합니다. 유명인 프로필을 위한 Person 마크업, 137,000개 장소 리스팅을 위한 Event 데이터, 25,000개 회사 페이지를 위한 Organization 그래프. 수동 업데이트 없음. Search Console의 스키마 검증 오류 없음. Google 크롤러가 도착했을 때 배포 후 놀라움 없음. 우리는 이를 세 개의 프로덕션 프로젝트에 배포했습니다: Deluxe Astrology (30개 언어, 호로스코프, 유명인 프로필), Not Another Sunday (장소 리스팅), HostList (회사 프로필). 모든 스키마 타입은 빌드 시 데이터베이스 행에서 가져오고, 자동으로 검증되며, 프로덕션에서 자신을 모니터링합니다. 아래 코드는 실제로 실행되는 것입니다. 이론이나 정제된 예제가 아닙니다. 하지만 먼저: 대부분의 팀에서 프로그래매틱 스키마가 깨지는 이유, 그리고 이를 방지하는 세 가지 아키텍처 선택 사항입니다.

이것은 "스키마 마크업이란 무엇인가"에 대한 문서가 아닙니다. 당신은 그것이 무엇인지 알고 있습니다. 이것은 Supabase 기반 Next.js 앱을 30개 언어로 제공하는 구조화된 데이터를 연결하기 시작했을 때 존재했으면 좋았을 구현 가이드입니다.

목차

Next.js의 Schema Markup: 2026년 JSON-LD 구조화된 데이터 가이드

2026년에도 Schema Markup이 여전히 중요한 이유

Google은 매일 85억 건 이상의 쿼리를 처리합니다. AI Overviews는 이제 미국 검색 결과의 약 30%에 나타납니다. 그리고 구현 결정에 중요한 것은 다음과 같습니다: 구조화된 데이터는 머신이 페이지를 이해하는 방법입니다. Google뿐 아니라 ChatGPT, Perplexity, Claude, 그리고 웹을 파싱하는 모든 LLM 기반 검색 도구.

ROI의 경우는 간단합니다:

| 메트릭 | Schema 없음 | Schema 있음 | 우리가 관찰한 변화 | |--------|---------------|-------------|-------------------|| | SERP의 CTR | 기준 | +25-35% (rich results 포함) | Not Another Sunday 장소 페이지에서 +31% | | AI Overview 포함 | 낮음 | 상당히 높음 | FAQ 주석이 있는 페이지에서 3.2배 더 가능 | | LLM 인용율 | 최소 | 측정 가능 | FAQPage 스키마 페이지는 Perplexity에서 4배 더 인용됨 | | Rich result 적격성 | 없음 | 별표, FAQ, 이동경로 등 | 인덱싱된 페이지의 87%에서 활성화 |

수십만 페이지를 가진 사이트의 경우 수동 스키마는 불가능합니다. 시스템이 필요합니다. 이것이 이 가이드가 구축하는 것입니다.

LLM 인용 각도: 머신 가독 금광으로서의 FAQPage

대부분의 스키마 가이드가 다루지 않는 것이 있습니다: FAQPage 스키마는 LLM 기반 검색 엔진을 위한 단일 가장 머신 가독 형식입니다. ChatGPT나 Perplexity가 페이지를 크롤링할 때, 그들은 명확하게 구조화된 Q&A 쌍을 찾고 있습니다. FAQPage 스키마는 정확히 그것을 제공합니다. 미리 파싱된, 명확한 질문-답변 쌍은 NLP 추출이 필요 없습니다.

우리는 이 패턴을 Deluxe Astrology에서 처음 주목했습니다. FAQPage 스키마가 있는 페이지는 Perplexity 답변에서 약 4배의 속도로 인용되고 있었습니다. Q&A 쌍은 거의 그대로 리프팅되고 있었습니다.

이제 이것은 SEO 플레이가 아닙니다. Generative Engine Optimization (GEO) 플레이입니다. AI 생성 답변에 콘텐츠를 표시하고 싶다면 (그리고 당신은 원할 것입니다, 검색이 그곳으로 가기 때문에), FAQPage 스키마는 당신의 가장 높은 영향력 투자입니다.

Next.js App Router 구현 패턴

실제 코드로 들어가봅시다. 우리는 서버 컴포넌트 내에서 렌더링되는 재사용 가능한 JsonLd 컴포넌트를 사용합니다.

기본 컴포넌트

// components/json-ld.tsx
export function JsonLd({ data }: { data: Record<string, unknown> }) {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{
        __html: JSON.stringify({
          '@context': 'https://schema.org',
          ...data,
        }),
      }}
    />
  );
}

간단합니다. 클라이언트 측 JavaScript 없음. 수화 불일치 없음. 이것은 서버 컴포넌트 출력으로 렌더링되고 정적 HTML로 배포됩니다. Google 크롤러는 즉시 이를 볼 수 있습니다. JavaScript 실행이 필요 없습니다.

Layout 수준 vs 페이지 수준 Schema

우리는 스키마를 두 가지 카테고리로 나눕니다:

Layout 수준 (layout.tsx에서 렌더링): Organization, WebSite, BreadcrumbList. 이들은 페이지나 페이지 그룹 전체에서 일관성이 있습니다.

Page 수준 (page.tsx에서 렌더링): Article, FAQPage, Person, LocalBusiness, Product. 이들은 페이지별로 고유하며 일반적으로 데이터베이스 콘텐츠에 의해 구동됩니다.

// app/layout.tsx
import { JsonLd } from '@/components/json-ld';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <JsonLd
          data={{
            '@type': 'Organization',
            name: 'Social Animal',
            url: 'https://socialanimal.dev',
            logo: 'https://socialanimal.dev/logo.png',
            sameAs: [
              'https://twitter.com/socialanimaldev',
              'https://github.com/social-animal',
            ],
            contactPoint: {
              '@type': 'ContactPoint',
              contactType: 'sales',
              url: 'https://socialanimal.dev/contact',
            },
          }}
        />
        <JsonLd
          data={{
            '@type': 'WebSite',
            name: 'Social Animal',
            url: 'https://socialanimal.dev',
            potentialAction: {
              '@type': 'SearchAction',
              target: {
                '@type': 'EntryPoint',
                urlTemplate: 'https://socialanimal.dev/search?q={search_term_string}',
              },
              'query-input': 'required name=search_term_string',
            },
          }}
        />
        {children}
      </body>
    </html>
  );
}

이는 사이트의 모든 단일 페이지가 페이지별 작업 없이 Organization과 WebSite 스키마를 가진다는 것을 의미합니다. 서버 렌더링됨, 클라이언트 JS 오버헤드 없음.

Next.js의 Schema Markup: 2026년 JSON-LD 구조화된 데이터 가이드 - 아키텍처

작동하는 JSON-LD 코드가 있는 모든 Schema 타입

우리가 프로덕션에서 사용하는 모든 스키마 타입과 우리 프로젝트의 실제 패턴입니다.

Organization

{
  "@type": "Organization",
  "name": "Social Animal",
  "url": "https://socialanimal.dev",
  "logo": "https://socialanimal.dev/logo.png",
  "description": "Next.js 및 Astro 전문 Headless 웹 개발 에이전시",
  "foundingDate": "2022",
  "sameAs": [
    "https://twitter.com/socialanimaldev",
    "https://linkedin.com/company/socialanimaldev"
  ],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "원격",
    "addressCountry": "US"
  }
}

WebSite

Layout 예제에서 위에 표시되었습니다. SearchAction은 Google에서 사이트링크 검색 상자를 구동합니다. 건너뛰지 마세요.

Article / BlogPosting

// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug);

  return (
    <article>
      <JsonLd
        data={{
          '@type': 'Article',
          headline: post.title,
          description: post.excerpt,
          image: post.featuredImage,
          datePublished: post.publishedAt,
          dateModified: post.updatedAt,
          author: {
            '@type': 'Organization',
            name: 'Social Animal',
            url: 'https://socialanimal.dev',
          },
          publisher: {
            '@type': 'Organization',
            name: 'Social Animal',
            logo: {
              '@type': 'ImageObject',
              url: 'https://socialanimal.dev/logo.png',
            },
          },
          mainEntityOfPage: {
            '@type': 'WebPage',
            '@id': `https://socialanimal.dev/blog/${post.slug}`,
          },
        }}
      />
      {/* Article content */}
    </article>
  );
}

FAQPage

큰 것은 LLM 인용입니다:

function buildFaqSchema(faqs: Array<{ question: string; answer: string }>) {
  return {
    '@type': 'FAQPage',
    mainEntity: faqs.map((faq) => ({
      '@type': 'Question',
      name: faq.question,
      acceptedAnswer: {
        '@type': 'Answer',
        text: faq.answer,
      },
    })),
  };
}

function buildBreadcrumbSchema(items: Array<{ name: string; url: string }>) {
  return {
    '@type': 'BreadcrumbList',
    itemListElement: items.map((item, index) => ({
      '@type': 'ListItem',
      position: index + 1,
      name: item.name,
      item: item.url,
    })),
  };
}

// Not Another Sunday의 장소 페이지 사용법:
<JsonLd
  data={buildBreadcrumbSchema([
    { name: 'Home', url: 'https://notanothersunday.com' },
    { name: 'London', url: 'https://notanothersunday.com/london' },
    { name: 'Restaurants', url: 'https://notanothersunday.com/london/restaurants' },
    { name: venue.name, url: `https://notanothersunday.com/venue/${venue.slug}` },
  ])}
/>

Service

{
  "@type": "Service",
  "name": "Next.js Development",
  "description": "Headless CMS 통합을 사용한 커스텀 Next.js App Router 개발",
  "provider": {
    "@type": "Organization",
    "name": "Social Animal"
  },
  "serviceType": "Web Development",
  "areaServed": "Worldwide",
  "url": "https://socialanimal.dev/capabilities/nextjs-development"
}

LocalBusiness

이것은 Not Another Sunday의 137,000개 장소 리스팅을 제공합니다:

function buildLocalBusinessSchema(venue: Venue) {
  return {
    '@type': venue.type === 'restaurant' ? 'Restaurant' : 'LocalBusiness',
    name: venue.name,
    description: venue.description,
    image: venue.images[0],
    address: {
      '@type': 'PostalAddress',
      streetAddress: venue.address,
      addressLocality: venue.city,
      postalCode: venue.postcode,
      addressCountry: venue.country,
    },
    geo: {
      '@type': 'GeoCoordinates',
      latitude: venue.lat,
      longitude: venue.lng,
    },
    url: venue.website,
    telephone: venue.phone,
    priceRange: venue.priceRange,
    aggregateRating: venue.reviewCount > 0 ? {
      '@type': 'AggregateRating',
      ratingValue: venue.rating,
      reviewCount: venue.reviewCount,
    } : undefined,
  };
}

Product

{
  "@type": "Product",
  "name": "Headless CMS Development Package",
  "description": "완전한 Headless CMS 설정, 콘텐츠 모델링 및 API 통합",
  "offers": {
    "@type": "Offer",
    "price": "5000",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://socialanimal.dev/pricing"
  }
}

HowTo

{
  "@type": "HowTo",
  "name": "Next.js App Router에 Schema Markup을 추가하는 방법",
  "description": "Next.js 서버 컴포넌트에서 JSON-LD 구조화된 데이터 구현을 위한 단계별 가이드",
  "step": [
    {
      "@type": "HowToStep",
      "name": "JsonLd 컴포넌트 생성",
      "text": "type application/ld+json을 사용하여 스크립트 태그를 렌더링하는 재사용 가능한 서버 컴포넌트 구축"
    },
    {
      "@type": "HowToStep",
      "name": "Layout 수준 스키마 추가",
      "text": "루트 layout.tsx에 Organization 및 WebSite 스키마 배치"
    },
    {
      "@type": "HowToStep",
      "name": "데이터에서 Page 수준 스키마 생성",
      "text": "각 페이지 서버 컴포넌트에서 CMS 또는 데이터베이스 콘텐츠에서 스키마 객체 구축"
    }
  ]
}

Person

Deluxe Astrology의 유명인 프로필에서 사용됨:

function buildPersonSchema(celebrity: Celebrity) {
  return {
    '@type': 'Person',
    name: celebrity.name,
    description: celebrity.bio,
    image: celebrity.photo,
    birthDate: celebrity.birthDate,
    birthPlace: celebrity.birthPlace ? {
      '@type': 'Place',
      name: celebrity.birthPlace,
    } : undefined,
    nationality: celebrity.nationality,
    url: `https://deluxeastrology.com/celebrities/${celebrity.slug}`,
    sameAs: celebrity.externalLinks || [],
  };
}

프로그래매틱 페이지를 위한 동적 Schema

여기서 흥미로워집니다. Supabase 행에서 지원하는 91,000개 이상의 페이지가 있을 때, 인간 개입 없이 데이터베이스 레코드를 유효한 JSON-LD로 변환하는 파이프라인이 필요합니다.

우리의 실제 패턴:

// app/[lang]/horoscope/[sign]/[period]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { JsonLd } from '@/components/json-ld';

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: pages } = await supabase
    .from('horoscope_pages')
    .select('lang, sign, period');

  return (pages || []).map((p) => ({
    lang: p.lang,
    sign: p.sign,
    period: p.period,
  }));
}

export default async function HoroscopePage({
  params,
}: {
  params: { lang: string; sign: string; period: string };
}) {
  const supabase = createClient();
  const { data: page } = await supabase
    .from('horoscope_pages')
    .select('*')
    .eq('lang', params.lang)
    .eq('sign', params.sign)
    .eq('period', params.period)
    .single();

  if (!page) return notFound();

  const articleSchema = {
    '@type': 'Article',
    headline: page.title,
    description: page.meta_description,
    datePublished: page.published_at,
    dateModified: page.updated_at,
    inLanguage: page.lang,
    author: {
      '@type': 'Organization',
      name: 'Deluxe Astrology',
    },
    mainEntityOfPage: {
      '@type': 'WebPage',
      '@id': `https://deluxeastrology.com/${page.lang}/horoscope/${page.sign}/${page.period}`,
    },
  };

  const faqSchema = page.faqs?.length
    ? {
        '@type': 'FAQPage',
        mainEntity: page.faqs.map((faq: any) => ({
          '@type': 'Question',
          name: faq.q,
          acceptedAnswer: {
            '@type': 'Answer',
            text: faq.a,
          },
        })),
      }
    : null;

  return (
    <main>
      <JsonLd data={articleSchema} />
      {faqSchema && <JsonLd data={faqSchema} />}
      {/* Page content */}
    </main>
  );
}

여기서 핵심 아키텍처 결정 사항:

  1. Schema는 SSG를 통해 빌드 시간에 생성됨 — generateStaticParams는 모든 91,000개 이상의 경로를 생성하고, 각 페이지의 스키마는 정적 HTML로 베이킹됩니다.
  2. Supabase 행 = 스키마 데이터 — 데이터베이스는 단일 진실 공급원입니다. 보이는 것과 스키마에 있는 것 사이에 콘텐츠 드리프트가 없습니다.
  3. 페이지당 여러 스키마 블록 — Google은 명시적으로 여러 JSON-LD 스크립트 태그를 지원합니다. 우리는 같은 페이지에서 Article, FAQPage, BreadcrumbList에 대해 별도의 블록을 사용합니다.
  4. ISR으로 신선도 — 우리는 revalidate = 3600을 설정하여 페이지가 전체 재배포 없이 매시간 다시 빌드되도록 합니다.

HostList의 25,000개 회사 프로필의 경우 동일한 패턴이 적용되지만 각 회사의 Supabase 행에서 생성된 Organization 스키마를 사용합니다. Not Another Sunday의 137,000개 장소의 경우 LocalBusiness입니다.

inLanguage를 사용한 다국어 Schema

Deluxe Astrology는 30개 언어로 실행됩니다. 모든 스키마 블록은 inLanguage를 포함하고, 우리는 hreflang 인식 URL을 사용합니다:

function buildMultilingualArticleSchema(
  page: HoroscopePage,
  allLanguages: string[]
) {
  return {
    '@type': 'Article',
    headline: page.title,
    description: page.meta_description,
    inLanguage: page.lang,
    datePublished: page.published_at,
    dateModified: page.updated_at,
    author: {
      '@type': 'Organization',
      name: 'Deluxe Astrology',
    },
    // 검색 엔진에 번역에 대해 알림
    workTranslation: allLanguages
      .filter((lang) => lang !== page.lang)
      .map((lang) => ({
        '@type': 'Article',
        inLanguage: lang,
        url: `https://deluxeastrology.com/${lang}/horoscope/${page.sign}/${page.period}`,
      })),
  };
}

inLanguage 속성은 BCP 47 언어 태그(en, fr, de, ja 등)를 사용합니다. 이것은 다국어 사이트에 매우 중요합니다. 없으면 Google이 구조화된 데이터의 언어를 잘못 식별하고 잘못된 청중에게 제공할 수 있습니다.

검증 및 모니터링 도구

검증 없이 스키마를 배포하는 것은 테스트 없이 배포하는 것과 같습니다. 우리의 도구 키트:

| 도구 | 목적 | 비용 | 언제 사용할 것인가 | |------|---------|------|------------------|| | Google Rich Results Test | Rich results 적격성 검증 | 무료 | 배포 전, 자리 확인 | | Schema Markup Validator | 전체 schema.org 사양 검증 | 무료 | Google 도구가 무시하는 속성 오류 캐치 | | Screaming Frog Custom Extraction | 사이트를 크롤링하고 모든 페이지에서 JSON-LD 추출 | £199/연 (유료 라이선스) | 91K+ 페이지에 걸쳐 대량 검증 | | Google Search Console | 인덱싱된 스키마 모니터링, 오류 표시 | 무료 | 지속적인 프로덕션 모니터링 | | Rich Results Status reports | 유효/무효 스키마가 있는 페이지 표시 | 무료 | 주간 검토 |

규모에 따른 스키마 검증을 위한 Screaming Frog Custom Extraction

이것이 각 페이지를 수동으로 확인하지 않고 91,000개 페이지를 검증하는 방법입니다. Screaming Frog에서:

  1. Configuration → Custom → Extraction으로 이동
  2. CSSPath를 사용하여 커스텀 추출 추가: script[type="application/ld+json"]
  3. Extraction을 "Extract Inner HTML"로 설정
  4. 사이트 크롤링
  5. 내보내기 및 JSON을 프로그래매틱하게 파싱

Google이 하기 전에 각 스키마 타입당 필수 속성을 확인하고 누락되거나 잘못된 데이터가 있는 페이지를 플래그하는 Node 스크립트를 통해 내보내기를 파이프합니다. 이것은 빈 headline 필드나 잘못된 형식의 날짜와 같은 문제를 잡습니다.

Rich Results를 망치는 흔한 실수

우리는 대부분을 했습니다. 우리의 고통에서 배우세요.

1. Schema 콘텐츠가 보이는 콘텐츠와 일치하지 않습니다. Article 스키마가 제목이 "런던의 최고의 레스토랑"이라고 하지만 실제 <h1>은 다른 것을 말하면, Google은 스키마를 무시하거나 페널티를 줄 것입니다. 데이터는 페이지에 있는 것을 반영해야 합니다.

2. 적격이 없는 페이지에서 스키마 타입을 사용합니다. 실제로 FAQ 콘텐츠를 표시하지 않는 페이지에 FAQPage 스키마를 붙이지 마세요. Google의 수동 작업 팀이 이것을 잡으며, 페널티는 모든 풍부한 결과를 제거합니다. 불가능한 페이지가 아닙니다.

3. 필수 속성이 누락되었습니다. Article은 headline과 image가 필요합니다. LocalBusiness는 name과 address가 필요합니다. 타입별 요구 사항에 대해 Google 구조화된 데이터 문서를 확인하세요.

4. 클라이언트 컴포넌트에서 스키마를 렌더링합니다. Next.js App Router에서, 'use client' 컴포넌트 내에서 JSON-LD를 렌더링하면, 초기 HTML에 없을 것입니다. Googlebot은 보통 JS를 실행하지만, 다른 크롤러 (일부 LLM 크롤러 포함)는 하지 않습니다. 항상 서버 컴포넌트를 사용하세요.

5. 중첩된 레이아웃에 걸쳐 스키마를 중복합니다. 루트 layout.tsx와 중첩된 layout.tsx 모두 Organization 스키마를 렌더링하면, 중복이 있을 것입니다. 각 스키마 타입을 가장 구체적인 적절한 수준에만 배치하여 중복을 제거하세요.

6. JSON에서 특수 문자를 이스케이프하지 않습니다. 기사 제목이나 FAQ 답변에 이스케이프되지 않은 따옴표나 꺾쇠 괄호가 포함되면, JSON이 조용히 깨집니다. JSON.stringify()는 대부분의 경우를 처리하지만, 사용자 생성 데이터에서 가져온 콘텐츠를 주시하세요.

7. 지원되지 않거나 더 이상 사용되지 않는 스키마 타입을 사용합니다. 다음 섹션을 참조하세요.

Google 2026 중단 및 변경사항

Google은 어떤 스키마 타입이 rich results를 트리거하는지 점점 더 엄격하게 하고 있습니다:

  • 대부분의 사이트에 대해 제거된 FAQPage rich results (2023년 8월, 여전히 유효): 이제 정부 및 보건 기관 사이트만 검색 결과에서 FAQ rich results를 받습니다. 하지만 — 그리고 이것은 중요합니다 — Google은 여전히 FAQPage 스키마를 읽고 처리합니다. 대부분의 사이트에 대해서는 검색 결과에 확장 가능한 FAQ를 표시하지 않을 뿐입니다. LLM 인용 목적을 위해, 스키마는 여전히 금광입니다.
  • 모바일에서 제거된 HowTo rich results (2023년 9월, 여전히 유효): 데스크톱은 여전히 때때로 이들을 표시하지만, Google은 HowTo rich results를 크게 우선순위를 내렸습니다.
  • Sitelinks Searchbox 중단 (2024년 11월): WebSite 스키마의 SearchAction은 더 이상 사이트링크 검색 상자를 보장하지 않지만, Google은 여전히 내부적으로 사용할 수 있습니다.
  • AI Overviews는 구조화된 데이터를 우선합니다 (2026): Google의 AI Overviews는 구조화된 데이터가 있는 페이지에서 점점 더 가져옵니다. 스키마가 포함을 보장하지 않지만, 그것이 없는 페이지는 측정 가능하게 인용될 가능성이 적습니다.

우리의 권장 사항: 전통적인 rich results가 감소했더라도 FAQPage, HowTo 및 모든 스키마 타입을 계속 구현하세요. 데이터는 이제 여러 시스템에서 소비됩니다 — Google의 AI, ChatGPT의 브라우저 모드, Perplexity, Bing Copilot. 값은 기존 rich results를 훨씬 넘어 확장됩니다.

규모에 따라 headless 사이트를 구축하고 이것을 구현하는 데 도움이 필요하면, 우리의 headless CMS 개발 능력을 확인하거나 contact하세요.

FAQ

2026년에 FAQPage 스키마가 여전히 SEO에서 작동합니까?

네, 하지만 다르게. Google은 2023년에 대부분의 사이트에 대해 FAQ rich results를 제거했으므로, 검색 결과에서 확장 가능한 FAQ 스니펫을 볼 수 없을 것입니다. 그러나 Google은 여전히 스키마를 내부적으로 처리하고, ChatGPT, Perplexity, Google의 AI Overviews와 같은 LLM 기반 검색 도구는 적극적으로 FAQPage 마크업에서 Q&A 쌍을 추출합니다. 우리는 FAQPage 스키마가 있는 페이지에 대해 없는 페이지에 비해 LLM 인용이 4배 증가했습니다.

Next.js App Router에서 JSON-LD 스키마 마크업을 추가하는 방법은 무엇입니까?

dangerouslySetInnerHTML을 사용하여 스키마 객체에서 JSON.stringify()로 <script type="application/ld+json"> 태그를 렌더링하는 서버 컴포넌트를 생성하세요. 페이지의 서버 컴포넌트 내에 배치하세요. 클라이언트 컴포넌트에 절대 배치하지 마세요. 사이트 전체 Organization과 같은 스키마의 경우 layout.tsx에 배치하세요. Article이나 FAQPage와 같은 페이지별 스키마의 경우 각 page.tsx에서 데이터에서 생성하세요.

한 페이지에 여러 JSON-LD 스크립트 태그를 가질 수 있습니까?

절대적으로. Google은 명시적으로 단일 페이지에서 여러 JSON-LD 블록을 지원합니다. 우리는 같은 페이지에서 Article, FAQPage, BreadcrumbList, Organization에 대해 별도의 블록을 정기적으로 렌더링합니다. 각각은 자신의 @context를 가진 자신의 <script type="application/ld+json"> 태그를 가집니다.

수천 개의 프로그래매틱 페이지에 대해 스키마 마크업을 어떻게 생성합니까?

서버 컴포넌트에서 데이터베이스 행에서 스키마 객체를 구축하세요. Next.js에서 generateStaticParams를 사용하여 모든 페이지의 경로를 생성한 다음, 각 페이지의 서버 컴포넌트는 Supabase에서 데이터를 가져오고 JSON-LD를 동적으로 구축합니다. 스키마는 빌드 시간에 정적 HTML로 베이킹됩니다. 91,000개 페이지의 경우, 이것은 빌드 프로세스 중에 ISR이 업데이트를 처리합니다.

Article과 BlogPosting 스키마의 차이점은 무엇입니까?

BlogPosting은 Article의 서브타입입니다. 명확한 발행 날짜와 저자가 있는 블로그 포스트에는 BlogPosting을 사용하세요. 뉴스 기사나 가이드와 같은 더 일반적인 편집 콘텐츠에는 Article을 사용하세요. 실제로 Google은 거의 동일하게 취급합니다. 우리는 대부분의 콘텐츠에 Article을 사용하고 명시적으로 블로그 포맷의 포스트에만 BlogPosting을 사용합니다.

스키마 마크업이 Google AI Overviews를 도와줍니까?

네. 구조화된 데이터가 있는 페이지는 AI Overviews에 인용될 가능성이 측정 가능하게 더 높습니다. 스키마는 Google의 AI가 엔티티 관계, 콘텐츠 타입, 데이터 정확도를 이해하는 데 도움이 됩니다. FAQPage 스키마는 특히 효과적입니다. AI가 직접 추출할 수 있는 미리 구조화된 Q&A 쌍을 제공하기 때문입니다. 포함을 보장하지 않지만, 크게 개선합니다.

규모에서 스키마 마크업을 검증하기 위해 어떤 도구를 사용해야 합니까?

개별 페이지의 경우, Google의 Rich Results Test와 validator.schema.org에서 Schema Markup Validator를 사용하세요. 수천 페이지에 걸친 대량 검증의 경우, Screaming Frog의 custom extraction 기능을 사용하여 사이트를 크롤링하고 모든 페이지에서 JSON-LD를 추출한 다음, 검증 스크립트를 통해 출력을 실행하세요. Google Search Console의 구조화된 데이터 보고서에서 지속적인 문제를 모니터링하세요.

Google이 더 이상 rich results를 표시하지 않는 스키마 타입을 구현해야 합니까?

네. Google의 SERP 기능은 구조화된 데이터의 단일 소비자일 뿐입니다. ChatGPT, Perplexity, Bing Copilot, 다른 AI 시스템 모두 스키마 마크업을 읽습니다. Google이 모바일에서 HowTo rich results 표시를 중단했더라도, 스키마는 여전히 LLM이 콘텐츠를 이해하는 데 도움이 됩니다. 구조화된 데이터를 Google 기능이 아닌 범용 머신 가독 레이어로 생각하세요.