91,000개 프로그래매틱 페이지에 구조화된 데이터 구현하기

91,000개 이상의 프로그래매틱 페이지에 구조화된 데이터를 배포했습니다. 오타가 아닙니다. 세 개의 프로덕션 프로젝트 — Deluxe Astrology (30개 언어, 호로스코프, 셀러브리티 프로필), Not Another Sunday (137,000개 장소 목록), HostList (25,000개 회사 프로필) — 에서 빌드 시간에 데이터베이스 행에서 JSON-LD 스키마를 생성하고, 자동으로 검증하고, 프로덕션에서 모니터링하는 시스템을 구축했습니다. 이것이 우리가 학습한 모든 것을 실제로 사용할 수 있는 작동 코드로 정제한 것입니다.

이것은 "스키마 마크업이란 무엇인가" 기사가 아닙니다. 그게 뭔지 알고 있습니다. 이것은 30개 언어를 지원하는 Supabase 기반 Next.js 앱에 구조화된 데이터를 연결하기 시작했을 때 존재했으면 하는 구현 가이드입니다.

목차

Schema Markup in Next.js: JSON-LD Structured Data Guide for 2026

2026년에도 스키마 마크업이 중요한 이유

Google은 매일 85억 개 이상의 쿼리를 처리합니다. AI 개요는 이제 미국의 검색 결과의 약 30%에 표시됩니다. 구현 결정에 중요한 것은 다음과 같습니다. 구조화된 데이터는 머신이 페이지를 이해하는 방식입니다. Google뿐만 아니라 — ChatGPT, Perplexity, Claude 및 웹을 파싱하는 모든 다른 LLM 기반 검색 도구입니다.

ROI 사례는 간단합니다:

메트릭 스키마 없음 스키마 있음 관찰된 증가
SERP에서의 CTR 기준 리치 결과로 +25-35% Not Another Sunday 장소 페이지에서 +31%
AI 개요 포함 낮음 상당히 높음 FAQ 주석 페이지에서 3.2배 더 높음
LLM 인용율 최소 측정 가능 Perplexity에서 FAQPage 스키마 페이지는 4배 더 자주 인용됨
리치 결과 적격성 없음 별, FAQ, 브레드크럼 등 인덱싱된 페이지의 87%에서 활성

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

LLM 인용 관점: 기계 판독 가능 골드로서의 FAQPage

여기 대부분의 스키마 가이드에서 다루지 않는 것이 있습니다: FAQPage 스키마는 LLM 기반 검색 엔진에 대한 단일 최고 기계 판독 형식입니다. ChatGPT나 Perplexity가 페이지를 크롤할 때, 명확하게 구조화된 Q&A 쌍을 찾고 있습니다. FAQPage 스키마는 이들에게 정확히 그것을 제공합니다 — 사전 파싱되고, 명확한 질문-답변 쌍으로, NLP 추출이 필요하지 않습니다.

우리는 Deluxe Astrology에서 먼저 이 패턴을 알아챘습니다. FAQPage 스키마를 가진 페이지는 이를 사용하지 않은 동등한 페이지보다 Perplexity 답변에서 대략 4배 인용되었습니다. Q&A 쌍은 거의 그대로 인용되었습니다.

이것은 더 이상 단순한 SEO 플레이가 아닙니다. 이것은 생성형 엔진 최적화(GEO) 플레이입니다. AI 생성 답변에서 콘텐츠를 표시하고 싶다면 — 그리고 검색이 그곳으로 가고 있기 때문에 원해야 합니다 — FAQPage 스키마는 가장 높은 영향도 투자입니다.

Next.js App Router 구현 패턴

실제 코드로 들어가봅시다. 우리는 모든 Next.js 개발 프로젝트에서 일관된 패턴을 사용합니다: 서버 컴포넌트 내부에 렌더링되는 재사용 가능한 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.tsx에서 렌더링됨): Organization, WebSite, BreadcrumbList. 이것들은 페이지 또는 페이지 그룹 전체에서 일관성이 있습니다.

페이지 수준 (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 오버헤드 없음.

Schema Markup in Next.js: JSON-LD Structured Data Guide for 2026 - architecture

작동 코드가 포함된 모든 스키마 유형

여기 프로덕션에서 사용하는 모든 스키마 유형과 프로젝트의 실제 패턴입니다.

Organization

{
  "@type": "Organization",
  "name": "Social Animal",
  "url": "https://socialanimal.dev",
  "logo": "https://socialanimal.dev/logo.png",
  "description": "Headless web development agency specializing in Next.js and Astro",
  "foundingDate": "2022",
  "sameAs": [
    "https://twitter.com/socialanimaldev",
    "https://linkedin.com/company/socialanimaldev"
  ],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Remote",
    "addressCountry": "US"
  }
}

WebSite

레이아웃 예에서 위에 표시됨. 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,
    })),
  };
}

// Usage for a venue page on 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": "Custom Next.js App Router development with headless CMS integration",
  "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": "Complete headless CMS setup with content modeling and API integration",
  "offers": {
    "@type": "Offer",
    "price": "5000",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://socialanimal.dev/pricing"
  }
}

HowTo

{
  "@type": "HowTo",
  "name": "How to Add Schema Markup to Next.js App Router",
  "description": "Step-by-step guide to implementing JSON-LD structured data in Next.js server components",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Create a JsonLd component",
      "text": "Build a reusable server component that renders a script tag with type application/ld+json"
    },
    {
      "@type": "HowToStep",
      "name": "Add layout-level schema",
      "text": "Place Organization and WebSite schema in your root layout.tsx"
    },
    {
      "@type": "HowToStep",
      "name": "Generate page-level schema from data",
      "text": "Build schema objects from your CMS or database content in each page server component"
    }
  ]
}

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 || [],
  };
}

프로그래매틱 페이지를 위한 동적 스키마

이것은 흥미로워지는 곳입니다. 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. 스키마는 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를 포함한 다국어 스키마

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',
    },
    // Tell search engines about translations
    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 리치 결과 적격성 검증 무료 배포 전, 스팟 체크
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. 구성 → 사용자정의 → 추출로 이동
  2. CSSPath를 사용한 사용자정의 추출 추가: script[type="application/ld+json"]
  3. 추출을 "Extract Inner HTML"로 설정
  4. 사이트 크롤
  5. 내보내고 JSON을 파싱하여 프로그래매틱으로 검증

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

리치 결과를 망칠 일반적인 실수

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

1. 스키마 콘텐츠가 보이는 콘텐츠와 일치하지 않습니다. Article 스키마가 헤드라인이 "Best Restaurants in London"이라고 말하지만 실제 <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 2025-2026 지원 중단 및 변경 사항

Google은 어떤 스키마 유형이 리치 결과를 트리거하는지 점점 더 엄격하게 하고 있습니다:

  • 대부분 사이트에서 FAQPage 리치 결과 제거됨 (2023년 8월, 여전히 적용 중): 이제 정부 및 보건 기관 사이트만 SERP에서 FAQ 리치 결과를 얻습니다. 그러나 — 그리고 이것이 중요합니다 — Google은 여전히 FAQPage 스키마를 읽고 처리합니다. 단순히 대부분 사이트에서 검색 결과에 확장 가능한 FAQ를 표시하지 않습니다. LLM 인용 목적으로, 스키마는 여전히 금입니다.
  • 모바일에서 HowTo 리치 결과 제거됨 (2023년 9월, 여전히 적용 중): 데스크톱은 여전히 가끔 표시하지만, Google은 HowTo 리치 결과를 크게 우선순위를 낮췄습니다.
  • 사이트링크 검색상자 지원 중단 (2024년 11월): WebSite 스키마의 SearchAction은 더 이상 사이트링크 검색상자를 보장하지 않지만, Google은 여전히 내부적으로 사용할 수 있습니다.
  • AI 개요는 구조화된 데이터의 우선순위 (2025-2026): Google의 AI 개요는 구조화된 데이터가 있는 페이지에서 점점 더 끌어옵니다. 스키마는 포함을 보장하지 않지만, 이를 사용하지 않는 페이지는 인용될 가능성이 현저히 낮습니다.

우리의 권장사항: Google의 SERP 기능이 감소했더라도 FAQPage, HowTo 및 모든 스키마 유형 구현을 계속하세요. 데이터는 이제 여러 시스템에서 소비됩니다 — Google의 AI, ChatGPT의 브라우징 모드, Perplexity, Bing Copilot. 가치는 전통적인 리치 결과 이상으로 확장됩니다.

헤드리스 사이트를 구축하고 규모에 따라 구현하는 데 도움이 필요하면, 우리의 헤드리스 CMS 개발 기능을 확인하거나 연락하세요.

FAQ

FAQPage 스키마는 여전히 2026년 SEO에서 작동하나요? 예, 다르게 작동합니다. Google은 2023년 대부분 사이트에서 FAQ 리치 결과를 제거했으므로, 검색 결과에서 확장 가능한 FAQ 스니펫을 보지 못할 것입니다. 그러나 Google은 여전히 스키마를 내부적으로 처리하고, ChatGPT, Perplexity 및 Google의 AI 개요 같은 LLM 기반 검색 도구는 FAQPage 마크업에서 Q&A 쌍을 적극적으로 추출합니다. 우리는 FAQPage 스키마를 사용하지 않는 페이지와 비교해 FAQPage 스키마가 있는 페이지에서 LLM 인용이 4배 증가했습니다.

Next.js App Router에서 JSON-LD 스키마 마크업을 어떻게 추가하나요? <script type="application/ld+json"> 태그를 dangerouslySetInnerHTML과 함께 스키마 객체에 JSON.stringify()를 사용하여 렌더링하는 서버 컴포넌트를 만드세요. 페이지의 서버 컴포넌트 내부에 배치하세요 — 절대 클라이언트 컴포넌트에 배치하지 마세요. 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 개요를 돕나요? 예. 구조화된 데이터가 있는 페이지는 AI 개요에서 인용될 가능성이 현저히 높습니다. 스키마는 Google의 AI가 엔티티 관계, 콘텐츠 유형 및 데이터 정확성을 이해하는 데 도움이 됩니다. FAQPage 스키마는 AI가 직접 추출할 수 있는 사전 구조화된 Q&A 쌍을 제공하기 때문에 특히 효과적입니다. 포함을 보장하지 않지만, 가능성을 크게 개선합니다.

규모에서 스키마 마크업을 검증하기 위해 어떤 도구를 사용해야 하나요? 개별 페이지의 경우, Google의 Rich Results Test 및 validator.schema.org의 Schema Markup Validator를 사용하세요. 수천 개 페이지 전체에 대한 대량 검증의 경우, Screaming Frog의 사용자정의 추출 기능을 사용하여 사이트를 크롤하고 모든 JSON-LD를 추출한 다음, 검증 스크립트를 통해 출력을 실행합니다. Google Search Console의 구조화된 데이터 보고서에서 진행 중인 문제를 모니터링하세요.

Google이 더 이상 리치 결과를 표시하지 않는 스키마 유형을 구현해야 하나요? 예. Google의 SERP 기능은 구조화된 데이터의 한 소비자일 뿐입니다. ChatGPT, Perplexity, Bing Copilot 및 다른 AI 시스템은 모두 스키마 마크업을 읽습니다. Google이 모바일에서 HowTo 리치 결과 표시를 중단했더라도, 스키마는 여전히 LLM이 콘텐츠를 이해하는 데 도움이 됩니다. 구조화된 데이터를 단순히 Google 기능이 아니라 보편적인 기계 판독 가능 계층으로 생각하세요.