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 designated back-button hijacking a malicious practice and announced enforcement starting June 15, 2026; sites must remove or disable code that prevents expected browser 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:

• Web Guide (Search Labs): Google published an official announcement for Web Guide on Jul 24, 2025. Web Guide is an experimental, AI-organized results page that groups links by topic using a custom Gemini model and a query fan-out technique. Action: prioritize clear topical H2s, one-sentence section leads, and section-level anchors so models can assign and cite page sections. (Source: https://blog.google/products-and-platforms/products/search/web-guide-labs/)

• Schema.org v30.0: The current stable Schema.org release is Version 30.0 (published 2026-03-19). When asserting required schema types/properties in CI, validate against the v30.0 definition at https://schema.org/version/latest. (Source: https://schema.org/version/latest)

• llms.txt community spec: Use the community-maintained llms.txt format for LLM discovery and include an ISO lastUpdated timestamp to help downstream crawlers reason about freshness. (Source: https://llmstxt.org/)

• March 2026 broad core update: Google released a broad core update on 2026-03-27 with rollout complete on 2026-04-08 — expect volatility and wait at least one week after rollout completion before drawing hard conclusions. (Source: https://status.search.google.com/incidents/7eTbAa2jWdToLkraZj5y)

• Back-button hijacking enforcement: Google designated back-button hijacking a malicious practice and published a 2‑month notice with enforcement beginning June 15, 2026. Sites that intercept or prevent expected back navigation should remove those behaviors to avoid manual actions or demotions. (Coverage: https://searchengineland.com/google-search-to-penalize-back-button-hijacking-schemes-474167)

Fresh signals (sources)

• Google Web Guide announcement (Search Labs): https://blog.google/products-and-platforms/products/search/web-guide-labs/ (Jul 24, 2025)
• Schema.org latest release / v30.0: https://schema.org/version/latest (Published: 2026-03-19)
• llms.txt community spec: https://llmstxt.org/index.html
• Google Search March 2026 core update incident: https://status.search.google.com/incidents/7eTbAa2jWdToLkraZj5y (Released: 2026-03-27; Rollout complete: 2026-04-08)
• Back-button hijacking enforcement coverage: https://searchengineland.com/google-search-to-penalize-back-button-hijacking-schemes-474167 (Apr 13, 2026)

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 Schema.org v30.0: assert required fields (headline, datePublished, author) and open a PR with remediation guidance when failures occur.
• Weekly llms.txt integrity check: confirm public/llms.txt exists, includes a valid ISO lastUpdated line, and regenerate llms-full.txt from the sitemap on each publish event.
• Back‑button audit: CI scanner to detect history.pushState, onpopstate handlers, and common back-navigation interception patterns; flag pages for manual 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. Measure changes over 30–60 day windows post-deployment.

Contact

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