Workflow

Step 1: Keyword mapping

Map each target page to a primary keyword, 2–3 secondary keywords, and a user-intent bucket (informational, navigational, transactional, commercial).

Step 2: Implement generateMetadata in Next.js

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";
import { getPost } from "@/lib/posts";

type Props = { params: Promise<{ slug: string }> };

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPost(slug);
  if (!post) return {};

  return {
    title: `${post.title} | YourBrand`,
    description: post.excerpt.slice(0, 155),
    alternates: { canonical: `https://yourbrand.com/blog/${slug}` },
    openGraph: {
      title: post.title,
      description: post.excerpt.slice(0, 155),
      url: `https://yourbrand.com/blog/${slug}`,
      type: "article",
      images: [{ url: post.ogImage, width: 1200, height: 630 }],
    },
  };
}

Step 3: Entity gap analysis

1. Collect the top 10 SERP results for your primary keyword.
2. Extract named entities from each using an NLP tool or manual review.
3. Build a union set of entities and mark which ones your content covers.
4. Fill gaps with factual, sourced statements that naturally include missing entities.

Notes: for AI‑organized surfaces (Web Guide, Gemini) pay special attention to topical clusters — label sections with concise H2s that match cluster subjects so the model can map your content into the correct group. Web Guide is a Search Labs experiment (official announcement: https://blog.google/products-and-platforms/products/search/web-guide-labs/) that clusters links by topic using a Gemini model.

Step 4: JSON‑LD structured data

Add application/ld+json script tags for the relevant schema type. Prefer canonical terms from schema.org (see https://schema.org/version/latest) and validate JSON‑LD as part of CI.

// components/article-jsonld.tsx
export function ArticleJsonLd({ post }: { post: Post }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: post.title,
    author: { "@type": "Person", name: post.author },
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    image: post.ogImage,
    publisher: {
      "@type": "Organization",
      name: "YourBrand",
      logo: { "@type": "ImageObject", url: "https://yourbrand.com/logo.png" },
    },
  };
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Practical validation: include a CI job that checks generated JSON‑LD for required properties and flags failures. Example Node.js validator (lightweight, runs in CI):

// scripts/validate-jsonld.js
const fs = require('fs');
const glob = require('glob');
function extractJsonLd(html) {
  const match = html.match(/<script[^>]+type=\"application\/ld\+json\"[^>]*>([\s\S]*?)<\/script>/i);
  if (!match) return null;
  return JSON.parse(match[1]);
}
let ok = true;
for (const file of glob.sync('out/**/*.html')) {
  const html = fs.readFileSync(file, 'utf8');
  const json = extractJsonLd(html);
  if (!json) continue; // non-article pages may not include JSON-LD
  if (!json.headline || !json.datePublished || !json.author) {
    console.error(`Missing required schema fields in ${file}`);
    ok = false;
  }
}
if (!ok) process.exit(2);

Example GitHub Actions job (run nightly or on publish):

name: Validate JSON-LD
on:
  schedule:
    - cron: '0 3 * * *' # daily 03:00 UTC
  workflow_dispatch: {}
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build site
        run: npm ci && npm run build && npm run export
      - name: Run JSON-LD validator
        run: node scripts/validate-jsonld.js

Notes: this CI pattern validates that your site ships JSON‑LD with the minimum required fields; combine with schema.org/version/latest checks when a public validator is available. Schema.org v30.0 is the current stable release (published 2026-03-19); validate JSON‑LD types/properties against that release when you need a fixed reference (https://schema.org/version/latest).

Step 5: Set up llms.txt and llms-full.txt

llms.txt is a community discovery spec. Follow https://llmstxt.org for structure and parsing expectations.

Practical rules (updated):

• Place llms.txt at the site root. Keep the H1 and short blockquote summary concise.
• Use H2 sections with markdown lists of [name](url): short note entries to surface canonical sources.
• Add an explicit "last updated" ISO timestamp in the file header to help downstream crawlers reason about freshness (many LLM crawlers cache aggressively).
• Do not use llms.txt as access control — use robots.txt and proper authentication instead.
• Keep llms-full.txt size‑bounded. Many crawlers will cache snapshots; include only high‑value canonical pages and add update timestamps.

Minimal example (public/llms.txt):

# YourBrand

> YourBrand builds developer tools for X. Core docs and API below.

> lastUpdated: 2026-04-10T12:00:00Z

## Docs
- [Getting Started](https://yourbrand.com/docs/start): Quickstart and examples
- [API Reference](https://yourbrand.com/docs/api): Full API surface with examples

## Blog
- [How We Built X](https://yourbrand.com/blog/how-we-built-x): Engineering post with benchmarks

Node script: generate a simple llms-full.txt from your sitemap (example):

// scripts/generate-llms-full.js
const fs = require('fs');
const fetch = require('node-fetch');
(async function(){
  const sitemap = await fetch('https://yourbrand.com/sitemap.xml').then(r=>r.text());
  const urls = [...sitemap.matchAll(/<loc>(.*?)<\/loc>/g)].map(m=>m[1]);
  const lines = ['# YourBrand', '', `> Snapshot of key docs`, '', `> lastUpdated: ${new Date().toISOString()}`];
  lines.push('');
  lines.push('## Snapshot');
  for(const u of urls.slice(0,200)){
    lines.push(`- [${u}](${u}): snapshot`);
  }
  fs.writeFileSync('public/llms-full.txt', lines.join('\n'));
})();

(See llmstxt.org for parsing expectations and recommended ordering.)

Step 6: Platform-specific GEO signals and a Web Guide tactic

Web Guide optimization tactic (short):

• Break long articles into clearly labeled H2 sections that mirror likely subtopics (e.g., “Symptoms”, “Diagnosis”, “Treatment” for medical queries).
• Add a 1–2 sentence lead at the top of each H2 that summarizes the section (makes it easier for clustering models to assign your section to a topic bucket).
• Ensure each section has at least one named entity, one authoritative link, and an internal canonical anchor so aggregators can reference the section directly.

Examples

Example 1: Blog post metadata in Next.js App Router

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPost(slug);
  return {
    title: post.title,
    description: post.excerpt.slice(0, 155),
    alternates: { canonical: `https://example.com/blog/${slug}` },
    openGraph: {
      title: post.title,
      description: post.excerpt,
      type: "article",
    },
  };
}

Example 2: Entity density improvement

Before: "Our tool helps with SEO." After: "Our tool analyzes Google Search Console data, identifies keyword cannibalization, and generates schema markup compliant with Schema.org Article and FAQ types."

Decision tree

• Page needs to rank in Google → apply full keyword placement workflow
• Page targets AI search only → focus on entity density + llms.txt + direct answers
• Page targets both → apply both workflows; JSON‑LD and llms.txt are complementary
• Page is behind auth → skip SEO; focus on UX and internal search
• Content is thin (< 300 words) → expand with entity-rich paragraphs before optimizing

Edge cases and gotchas

1. Keyword stuffing penalties — Google penalizes unnatural repetition. Keep primary keyword density between 1–2%. Use semantic variants instead of exact repeats.
2. Duplicate metadata across pages — every page needs unique title and description. Use generateMetadata dynamically, never hardcode the same string.
3. JavaScript-rendered content — Google renders JS but some AI crawlers may not. Ensure SSR or SSG for all indexable content. Test with curl to verify immediate HTML output.
4. Canonical conflicts — a page with both a self-referencing canonical and a redirect will confuse crawlers. Pick one source of truth.
5. llms.txt freshness — AI crawlers cache aggressively. Add lastUpdated timestamps to llms.txt / llms-full.txt and update when you publish or remove important pages. Use the llms.txt community spec for structure (https://llmstxt.org/).
6. Over-optimizing for one AI platform — each AI search engine weights signals differently. Optimize for the union of signals, not a single platform.
7. Search Console data anomalies and recent core updates — Google completed a March 2026 broad core update (released 2026-03-27; rollout complete 2026-04-08). Wait at least a full week after a core update completes before drawing conclusions from traffic data; compare date ranges carefully. (Source: https://status.search.google.com/incidents/7eTbAa2jWdToLkraZj5y)
8. AI fetcher bots and traffic siphoning — monitor server logs and analytics for non‑browser AI fetcher traffic (reports in 2026 show a rise in AI bot traffic that can affect publisher referral traffic). Consider bot identification and rate limits when appropriate.
9. Back-button hijacking enforcement — Google announced that back-button hijacking will be treated as a malicious practice and will be enforced starting June 15, 2026; sites must remove or disable code that prevents expected browser back navigation (common culprits: aggressive history.pushState/onpopstate handlers, modal loops, or scripts that intercept back navigation). (Coverage: https://searchengineland.com/google-search-to-penalize-back-button-hijacking-schemes-474167)

Evaluation criteria

• Every indexable page has a unique title, meta description, and canonical URL
• Primary keyword appears in title, H1, first 100 words, and at least one subheading
• JSON‑LD is valid and uses current schema.org terms (validate against https://schema.org/version/latest — Schema.org v30.0 published 2026-03-19)
• Entity coverage matches or exceeds top 3 SERP competitors
• llms.txt exists at the site root and follows the community spec (https://llmstxt.org) and includes a lastUpdated timestamp
• Page loads with SSR/SSG — content visible without JS execution
• Core Web Vitals pass (LCP < 2.5s, CLS < 0.1, INP < 200ms)
• No duplicate canonical URLs across the site
• Monitor Search Console and the Google Search Status Dashboard for core updates and impression reporting corrections
• Audit for back-button hijacking patterns and remove any handlers that block expected navigation (enforcement: June 15, 2026)

Research-backed changes

The biggest deltas since the last revision are:

• Google Search Labs Web Guide — experimental AI-organized SERP that clusters links by topic using a Gemini model (official announcement: https://blog.google/products-and-platforms/products/search/web-guide-labs/ published Jul 24, 2025). Prioritize topical H2 clusters and short section leads so pages can be assigned and cited at the section level.
• Schema.org — the live release is available at https://schema.org/version/latest; current stable release is Version 30.0 (published 2026-03-19). Validate JSON‑LD against that release when you require a fixed vocabulary.
• Google March 2026 broad core update (released 2026-03-27; rollout complete 2026-04-08) — expect ranking volatility during rollout windows; wait at least one week after completion before drawing conclusions from traffic changes. (Source: https://status.search.google.com/incidents/7eTbAa2jWdToLkraZj5y)
• Google designated "back button hijacking" a malicious practice and announced enforcement starting June 15, 2026 — sites that prevent expected back navigation risk manual spam actions or automated demotions. (Coverage: https://searchengineland.com/google-search-to-penalize-back-button-hijacking-schemes-474167)

Fresh signals (sources)

• Google Blog — Web Guide announcement: https://blog.google/products-and-platforms/products/search/web-guide-labs/ (official announcement; Jul 24, 2025)
• Google Search Status Dashboard — March 2026 core update incident: https://status.search.google.com/incidents/7eTbAa2jWdToLkraZj5y (incident timeline: released 2026-03-27; rollout complete 2026-04-08)
• Schema.org release listing and current version: https://schema.org/version/latest (Version 30.0, published 2026-03-19)
• Back button hijacking enforcement coverage: https://searchengineland.com/google-search-to-penalize-back-button-hijacking-schemes-474167

Next edits

• Add CI JSON‑LD validation example and a schema mapping table (Article → Article, LocalBusiness → LocalBusiness with floorLevel) — short scripts to validate against https://schema.org/version/latest (already included in CI script example)
• Add a lastUpdated header recommendation and example for llms.txt and llms-full.txt (already included)
• Add a small monitoring playbook: nightly JSON‑LD validation, weekly llms.txt integrity check, post‑core‑update traffic comparison windows, and a back‑button audit run weekly until enforcement passes

Experiments and monitoring

• Nightly JSON‑LD validation run against the site HTML to assert required schema fields (headline, datePublished, author).
• Weekly llms.txt integrity check: ensure public/llms.txt exists, includes a valid ISO lastUpdated line, and that llms-full.txt snapshot generation completes without errors.
• Back‑button audit: run a simple scanner in CI that searches for history.pushState, onpopstate handlers, and common back-navigation interception patterns; flag pages for manual review and remediation before June 15, 2026.
• A/B test: split long‑form pages into H2‑clustered sections (with one‑sentence leads) vs. monolithic article to measure citation and click differences in AI‑organized SERPs.

Contact

For detailed implementation help, include SERP samples, top 10 competitor URLs, and a sitemap so we can produce a focused entity‑gap plan.