That isn't a bug. It's how the system is designed, and Google documents it. This post explains why ranking and AI citation have drifted apart, what the studies measured, and how to use the gap instead of fighting it.

What the overlap studies found

In Ahrefs' 2026 data, the remaining citations split roughly evenly: about 31% from positions 11–100 and about 31% from pages that weren't in the top 100 at all.

Read these numbers carefully. The two Ahrefs studies count differently, and Ahrefs says its citation detection improved in between, so the drop from 76% to 38% is partly measurement. But even the high estimate leaves a quarter of citations outside the top 10, and the newer studies all point the same way.

Why it happens: query fan-out

Google's documentation for AI features says both AI Overviews and AI Mode "may use a 'query fan-out' technique — issuing multiple related searches across subtopics and data sources — to develop a response." It adds that this lets Google identify more supporting pages than classic search, "displaying a wider and more diverse set of helpful links."

So the system doesn't just look at the top results for the query you typed. Take:

"Is Supabase good for a production SaaS?"

That might fan out into:

• Supabase row-level security performance
• Supabase connection pooling limits
• Supabase pricing at 100k monthly active users
• Supabase vs Firebase vs Neon
• Supabase backups and point-in-time recovery

Each sub-query has its own results. A detailed post about Supabase connection pooling, ranking #40 for the head query, can be the best answer to one sub-question and get cited. A generic "Is Supabase good?" listicle ranking #2 may answer none of the sub-questions well and get skipped.

What this means for content strategy

1. The head-term page isn't enough. Ranking for "Supabase review" doesn't cover the questions a fan-out generates. You need pages, or clearly separated sections, that answer each sub-question.

2. Depth on narrow questions pays twice. A specific page ("Supabase connection pooling: Supavisor limits by plan") can rank for its own long-tail query and be pulled in as a supporting source for broader questions.

3. Section headings matter more. The retriever is matching passages to sub-queries. A heading that states the sub-question ("How many connections does Supabase allow on the Pro plan?") is easier to match than "Limits".

4. Don't assume your rank tracker tells the whole story. A page can lose rank and gain citations, or the reverse. Track them separately.

Find the sub-questions you're missing (Python)

You can't see Google's real fan-out queries. You can approximate them and check which ones your content covers. This script asks an LLM to generate likely sub-queries, then checks each against your page sections with embeddings.

# pip install openai numpy beautifulsoup4 requests
import json, requests, numpy as np
from bs4 import BeautifulSoup
from openai import OpenAI

client = OpenAI()

def fan_out(query, n=12):
    prompt = (f"A search engine expands the question below into {n} sub-queries "
              f"covering subtopics a complete answer needs. Return a JSON list of strings.\n\n{query}")
    r = client.chat.completions.create(model="gpt-4.1-mini", messages=[{"role": "user", "content": prompt}],
                                       response_format={"type": "json_object"})
    data = json.loads(r.choices[0].message.content)
    return next(iter(data.values())) if isinstance(data, dict) else data

def sections(url):
    soup = BeautifulSoup(requests.get(url, timeout=20).text, "html.parser")
    out, cur = [], None
    for el in soup.find_all(["h2", "h3", "p", "li", "td"]):
        if el.name in ("h2", "h3"):
            cur = {"heading": el.get_text(" ", strip=True), "text": ""}
            out.append(cur)
        elif cur:
            cur["text"] += " " + el.get_text(" ", strip=True)
    return [s for s in out if len(s["text"]) > 80]

def embed(texts):
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    v = np.array([d.embedding for d in r.data])
    return v / np.linalg.norm(v, axis=1, keepdims=True)

def coverage(query, urls, threshold=0.55):
    subs = fan_out(query)
    secs = [(u, s) for u in urls for s in sections(u)]
    S = embed([f'{s["heading"]}. {s["text"][:1500]}' for _, s in secs])
    Q = embed(subs)
    sims = Q @ S.T
    for i, q in enumerate(subs):
        j = int(sims[i].argmax())
        best = sims[i, j]
        mark = "OK " if best >= threshold else "GAP"
        print(f"{mark} {best:.2f}  {q}\n      → {secs[j][1]['heading']}  ({secs[j][0]})")

coverage("Is Supabase good for a production SaaS?",
         ["https://yourblog.dev/supabase-review", "https://yourblog.dev/supabase-pooling"])

Typical output:

OK  0.71  Supabase connection pooling limits by plan
      → How many connections does Supabase allow?  (…/supabase-pooling)
OK  0.63  Supabase row level security performance
      → Row-level security in practice  (…/supabase-review)
GAP 0.41  Supabase point-in-time recovery and backups
      → Pricing  (…/supabase-review)
GAP 0.38  Supabase vs Neon for serverless Postgres
      → Final verdict  (…/supabase-review)

Every GAP line is a sub-question where your content probably isn't the best passage. Fix the biggest ones with a new section or a new page.

Caveats: the generated sub-queries are a guess at Google's, not the real thing. The threshold depends on the embedding model; calibrate it by checking a few sections by hand. Run the fan-out a few times and merge the results, because LLM output varies.

Checking whether it worked

Coverage tells you whether you can answer the sub-questions. It doesn't tell you whether AI engines actually cite you. For that you need to look at the answers: run your important questions in Google AI Mode, ChatGPT and Perplexity on a schedule and record which URLs each one cites.

That's what Vista AI's AI Citation Tracking is built for. It records the prompt, the full answer and every cited source across the major AI engines, shows which of your pages get cited and which competitor pages are cited instead, and scores whether you were the primary source or a passing mention. Put that next to your rank tracker and the rank–citation gap becomes visible for your own keywords instead of an industry average.

Key takeaways

• In Ahrefs' 2026 data, only about 38% of AI Overview citations ranked in the top 10 for the same query. Other studies put it lower.
• The cause is query fan-out: AI features search for sub-questions and cite the best page for each.
• Narrow, deep pages win sub-questions, and question-shaped headings help retrievers match them.
• Approximate the fan-out with an LLM and check coverage with embeddings. Fix the gaps.
• Track citations separately from rank. They no longer move together.

Sources: Google Search Central, "AI features and your website"; Ahrefs AI Overview citation studies (2025, 2026) as reported; BrightEdge as reported.

This post collects what the studies actually measured, where they disagree, and what a developer who runs a blog, docs site or product site should change. It's the overview for the rest of this series: each of the next nine posts goes deep on one of these shifts.

Shift 1: fewer clicks per search on AI-answered queries

This is the best-measured change, and every study agrees on the direction.

The numbers don't match, and they shouldn't be expected to. They use different query sets, different time windows and different definitions of "click". Google also disputes the Pew methodology. But no study found that AI answers increase clicks per query on informational searches.

What it means for you: traffic from "what is X" and "how does X work" queries is the most exposed. Queries where the user has to do something on your site (sign up, download, compare plans, read the full tutorial) hold up better.

Shift 2: ranking and being cited are drifting apart

In 2025, Ahrefs found that about 76% of AI Overview citations came from pages in the top 10 for that query. Its 2026 analysis of 863,000 keywords put that figure at 38%, with the rest split roughly evenly between positions 11–100 and pages outside the top 100.

Two caveats. Ahrefs says its citation detection improved between the studies, so part of the drop is measurement. And other datasets give different overlaps (BrightEdge reported about 17%, varying a lot by industry).

The mechanism behind the gap is documented by Google: AI Overviews and AI Mode use query fan-out, "issuing multiple related searches across subtopics and data sources". Your page can be cited because it answers a sub-query well, even if it ranks nowhere for the main query. Post 10 covers how to use that.

Shift 3: the sources that get cited are not the sources that rank

Ask ChatGPT for a recommendation and look at the citations. Third-party sources dominate. Ahrefs' September 2026 tracking puts Reddit at about 17% of cited domains in ChatGPT and Wikipedia at about 7%. Other studies (Similarweb data via 5W) rank Wikipedia first. The order depends on the denominator, but the pattern is the same: forums, encyclopedias, review sites and comparison posts make up a large share.

Ahrefs also reported that brand web mentions correlated much more strongly with AI Overview visibility (around 0.66) than backlinks did (around 0.22). Correlation, not causation, but it matches what you see in the answers: models repeat what the web says about you, not just what you say about yourself. Post 13 covers this.

Shift 4: measurement now has two halves

Classic SEO measurement is one loop: Search Console impressions, clicks, positions. In 2026 you need a second one.

• What Google gives you. AI Overview and AI Mode traffic is counted in the normal Performance report under "Web". Since June 2026, Google has been rolling out separate Generative AI performance reports to a subset of sites. They show impressions from AI features, but not queries, clicks or CTR.
• What nobody gives you. ChatGPT, Perplexity, Claude and Copilot don't have a Search Console. To know whether they mention you, you have to ask them, repeatedly, and record the answers.

What didn't change

It's easy to over-correct. Several things are exactly as they were:

• Google's eligibility rules. Its documentation says there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary". A page must be indexed and eligible for a snippet.
• No magic file or markup. Google says you don't need "new machine readable files, AI text files, or markup". llms.txt is not used by Google Search.
• Crawlability and rendering. If a bot can't fetch your content or the content only exists after JavaScript runs, nothing downstream matters.
• Quality. Original information, clear structure and accurate facts help in classic ranking and in AI answers.

What to change: a short priority list

1. Audit access first. Check robots.txt, your CDN's bot rules and rate limits for Googlebot, Bingbot, OAI-SearchBot, PerplexityBot and Claude-SearchBot. Check that core content is in the raw HTML.
2. Restructure your best pages for passages. Question-shaped headings, the answer in the first sentence, sections that make sense on their own. (Post 11 has a Python demo of how retrievers chunk a page.)
3. Cover the sub-questions. For each important topic, list the follow-up questions a user (or a fan-out query) would ask and make sure one of your pages answers each clearly.
4. Refresh what's already cited. Studies of AI citations find most cited pages were updated recently, even if they were published years ago. (Post 12.)
5. Publish something only you have. Benchmarks, original data, real error messages, measured results. (Post 14.)
6. Earn mentions, not just links. Docs that others reference, honest comparison pages, community answers. (Posts 13 and 15.)
7. Get ready for agents. Google-Agent and other user-triggered fetchers are already in server logs, and shopping agents read product feeds instead of pages. (Posts 16 and 17.)
8. Measure both halves. Search Console for Google, repeated prompt sampling for the AI engines.

How to track the second half

The cheap way: write 20–30 questions your users actually ask, run them in ChatGPT, Perplexity, Gemini and Google AI Mode once a week, and log whether you're mentioned, whether you're cited and who's recommended instead. Do it for a month and you'll see the shape of your visibility.

It gets slow quickly, because answers vary run to run and a real picture needs many samples per prompt and engine. That's the part Vista AI's AI Rank Tracker automates: it runs your prompt set daily across ChatGPT, Gemini, Claude, Perplexity, Copilot and Google AI Mode, shows your position in each engine and rolls the results into a 0–100 visibility index you can track next to your Search Console data.

Key takeaways

• Clicks per query are down on AI-answered informational searches. Every study agrees on direction; none agree on size.
• Ranking ≠ citation. Query fan-out means pages outside the top 10 get cited, and top-10 pages often don't.
• Third-party sources carry weight. What Reddit, Wikipedia and review sites say about you feeds the answers.
• The fundamentals didn't change. Indexable, crawlable, server-rendered, original, accurate.
• Measure two loops: Search Console for Google, repeated sampling for everything else.

Sources: Google Search Central, "AI features and your website" (updated Dec 2025); Google Search Central blog, June 2026; Ahrefs AI Overview and ChatGPT citation studies (2025–2026); Seer Interactive; Pew Research Center. Figures from third-party studies are as reported by those studies.

The obvious method: type your key questions into ChatGPT, see if you show up, take a screenshot. The problem is that AI answers are non-deterministic. The same prompt returns different brands on different runs, in different engines, for different users. A screenshot is a sample size of one, and it's biased by your own chat history and location.

This post covers the five metrics worth tracking, how to collect them so they're statistically meaningful, and how to report them without misleading anyone.

Why GEO measurement is different from SEO measurement

The core shift: you're estimating a probability ("how often does this engine mention us for this question?"), not reading off a position.

Step 1: Build the prompt set

Your prompts are your sample frame. Get them wrong and every metric downstream is wrong.

• Write prompts the way users ask, not as keywords. "What's the best error tracking tool for a small Next.js team?" not "error tracking tool".
• Cover the buyer journey. Problem ("why do my Next.js errors not show stack traces?"), solution ("what tools track frontend errors?"), comparison ("Sentry vs Highlight"), decision ("is Sentry worth it for a 3-person team?").
• Start with 20–50. Enough to cover your category, few enough to review by hand.
• Freeze them. Editing a prompt's wording creates a new prompt. Version them, or your trend lines compare different questions.

Step 2: Sample properly

For each prompt, run it multiple times per engine on a schedule (daily is typical) and store every raw answer.

How many samples? The honest answer comes from confidence intervals. If a brand appears in 3 out of 10 answers, the 95% interval for its true mention rate is roughly 11% to 60%. That's too wide to act on. With 30 out of 100 it narrows to about 22–40%.

import math

def wilson(k, n, z=1.96):
    """95% Wilson score interval for a proportion k/n."""
    p = k / n
    d = 1 + z*z/n
    c = (p + z*z/(2*n)) / d
    h = z * math.sqrt(p*(1-p)/n + z*z/(4*n*n)) / d
    return max(0, c-h), min(1, c+h)

print(wilson(3, 10))    # ≈ (0.11, 0.60)
print(wilson(30, 100))  # ≈ (0.22, 0.40)

The practical rule: report rates over a window (7 or 28 days), and always show the sample size next to them.

The five metrics

1. Visibility rate

The share of answers that mention your brand, per engine, over a window.

SELECT engine,
       COUNT(*)                          AS answers,
       ROUND(AVG(mentioned) * 100, 1)    AS visibility_pct
FROM scored_answers
WHERE brand = 'Acme' AND run_date >= date('now', '-28 days')
GROUP BY engine;

Track it per engine. A single blended number hides the most useful pattern: you're often strong in one engine and invisible in another, and the causes differ.

2. Share of voice

Your share of all brand mentions across answers in your category, against a fixed set of competitors.

SELECT engine, brand,
       ROUND(1.0 * SUM(mentioned) / SUM(SUM(mentioned)) OVER (PARTITION BY engine), 3) AS sov
FROM scored_answers
WHERE run_date >= date('now', '-28 days')
GROUP BY engine, brand;

Two cautions: fix the competitor list (adding a brand mid-period shrinks everyone's share), and consider weighting by list position, because being recommended first is worth more than being listed fifth.

3. Citation rate (separate from mentions)

The share of answers that link to your domain as a source. Keep it separate from mentions:

• Mentioned, not cited: the engine knows you but sources claims about you elsewhere (reviews, forums, competitor comparisons). Those third-party pages are shaping your description.
• Cited, not mentioned: your content supports a general claim, but the answer recommends someone else.

They need different fixes, so merging them throws information away.

4. Sentiment / framing

How you're described when mentioned: recommended, neutral listing, or critical. Track it as a stacked share (positive / neutral / critical), not a single net score. A net score can stay flat while neutral mentions quietly turn critical.

If you classify sentiment with an LLM, hand-check a sample every month. Labels drift when the labelling model changes.

5. AI referral traffic

Visits from AI assistants, measured in analytics:

• Referrer hosts like chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com, claude.ai
• utm_source=chatgpt.com, which ChatGPT often appends to links

In GA4, create a custom channel group with a regex on Source and place it above Referral:

^(chatgpt\.com|chat\.openai\.com|(www\.)?perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai)$

Be clear about what this can't see: app clicks often arrive without a referrer, many users read the answer and never click, and Google's AI Overviews clicks are folded into Google organic. Referral traffic is a floor on AI influence, not a total.

Reporting: what goes on the dashboard

1. Visibility rate by engine, 7-day rolling, with sample sizes.
2. Share of voice by engine against 2–5 named competitors.
3. Mention vs. citation rate on one chart. The gap is the insight.
4. Sentiment mix, weekly stacked bars.
5. AI referral sessions, with a note that they're a floor.
6. A link to the raw answers behind every number. The first question in any review meeting is "what exactly did it say?"

And three traps to avoid:

• Average position alone. It can "improve" while you disappear: drop out of answers where you were listed fifth, and the average of what's left goes up.
• Averaging daily percentages. Sum numerators and denominators over the window instead, or a 4-sample day counts as much as a 40-sample day.
• One engine's trend as "AI search". Engines move independently, so report each one.

Build or buy

You can build all of this: a prompt table, a daily job calling the OpenAI and Perplexity APIs, a scorer, and SQL like the above. It gets heavy once you add more engines (Copilot and Google AI Mode don't offer the same simple APIs), regions, competitors and a UI people will actually open.

Vista AI's Brand Visibility Dashboard packages it: visibility overall and by engine, share of voice against competitors, sentiment split into positive, neutral and critical, per-query rankings, 30-day, 90-day and yearly trends, regional breakdowns, and weekly email reports. A raw data stream keeps the full AI response behind every number. For the competitor side specifically, Vista's Competitor Analysis shows where each rival beats you per engine and which of their pages get cited most.

Key takeaways

• GEO metrics are rates estimated from repeated samples, not positions.
• Track five things: visibility rate, share of voice, citation rate, sentiment, AI referrals.
• Keep mentions and citations separate.
• Show the denominator on every number and report each engine separately.
• Treat AI referral traffic as a floor, not the full effect.

So is structured data pointless for AI search? Also no. JSON-LD remains the most reliable way to state facts about your page in a form machines don't have to guess at: who you are, who wrote this, when it changed, what it costs. Search engines use it for rich results and entity understanding, and a page with clear, consistent facts is harder to misquote.

This post covers which types are worth adding in 2026, what's been retired, and how to implement and validate it without creating new problems.

What structured data does (and doesn't) do

It does:

• make rich results possible (review stars, product info, breadcrumbs, article info),
• state facts explicitly instead of leaving them to be inferred from prose,
• connect your pages to an entity (your organisation, your author profile) through @id and sameAs.

It doesn't:

• guarantee rich results (Google decides when to show them),
• get you into AI Overviews by itself,
• fix content that's thin, wrong or hard to read.

Rich results that changed, so you don't waste effort

Two that many tutorials still recommend:

• FAQ rich results have been limited to well-known, authoritative government and health websites since August 2023. FAQPage markup is still valid schema.org, but on most sites it won't produce the expandable FAQ result anymore.
• HowTo rich results were removed from Google Search in 2023.

You can keep FAQPage markup if your page genuinely has an FAQ (it's still a clear machine-readable structure), but don't add it expecting a SERP feature.

The types worth implementing

1. Organization (homepage)

Defines your brand as an entity and links your official profiles:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acmeanalytics.com/#org",
  "name": "Acme Analytics",
  "url": "https://acmeanalytics.com",
  "logo": "https://acmeanalytics.com/logo.png",
  "sameAs": [
    "https://github.com/acme-analytics",
    "https://www.linkedin.com/company/acme-analytics",
    "https://x.com/acmeanalytics"
  ]
}

sameAs matters for AI search in a practical way. When a model or search engine sees "Acme" on GitHub, LinkedIn and your site, consistent sameAs links help connect those mentions to one entity, which matters if your brand name is ambiguous.

2. BlogPosting / TechArticle (posts and docs)

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Fixing N+1 queries in Prisma with include",
  "description": "Why findUnique in a loop is slow, and how include and relationLoadStrategy fix it.",
  "datePublished": "2026-09-14",
  "dateModified": "2026-10-02",
  "author": {
    "@type": "Person",
    "name": "Sam Rivera",
    "url": "https://acmeanalytics.com/team/sam-rivera"
  },
  "publisher": { "@id": "https://acmeanalytics.com/#org" },
  "proficiencyLevel": "Intermediate",
  "dependencies": "Prisma 6, Node.js 22"
}

dateModified is the field that most often goes stale. Update it when the content meaningfully changes, not on every deploy.

3. SoftwareApplication or Product with offers (pricing pages)

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme Analytics",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": [
    { "@type": "Offer", "name": "Starter", "price": "49", "priceCurrency": "USD" },
    { "@type": "Offer", "name": "Growth", "price": "199", "priceCurrency": "USD" }
  ],
  "publisher": { "@id": "https://acmeanalytics.com/#org" }
}

Pricing is one of the facts AI answers get wrong most often, usually because an old price is still floating around the web. Correct, current offers on your own pricing page give engines an authoritative source.

4. BreadcrumbList (everything with hierarchy)

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Docs", "item": "https://acmeanalytics.com/docs" },
    { "@type": "ListItem", "position": 2, "name": "SDKs", "item": "https://acmeanalytics.com/docs/sdks" },
    { "@type": "ListItem", "position": 3, "name": "Node.js" }
  ]
}

Implementation: generate it from the same data as the page

The biggest structured data bug isn't a syntax error. It's drift: JSON-LD says $49, the page says $59, because someone updated one and not the other. Generate both from one source.

Next.js (App Router)

// app/pricing/page.tsx
import { plans } from "@/data/plans";   // the same data the pricing table renders

export default function PricingPage() {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "SoftwareApplication",
    name: "Acme Analytics",
    applicationCategory: "BusinessApplication",
    operatingSystem: "Web",
    offers: plans.map((p) => ({
      "@type": "Offer",
      name: p.name,
      price: String(p.monthlyPrice),
      priceCurrency: "USD",
    })),
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
        }}
      />
      <PricingTable plans={plans} />
    </>
  );
}

Two details:

• This renders in a Server Component, so the JSON-LD is in the raw HTML. JSON-LD injected client-side has the same problem as any client-rendered content: crawlers that don't run JavaScript won't see it.
• The replace(/</g, "\\u003c") escapes < so a value containing </script> can't break out of the tag. Next.js's own docs recommend this pattern.

Astro

---
import { plans } from "../data/plans";
const jsonLd = { "@context": "https://schema.org", "@type": "SoftwareApplication", /* … */ };
---
<script type="application/ld+json" set:html={JSON.stringify(jsonLd)} />

Hashnode, Ghost and other hosted platforms

Hosted blogging platforms, Hashnode included, generate basic article metadata for posts automatically. You usually don't need to add BlogPosting yourself. Put your effort into the Organization and Product markup on your main site, which the platform can't do for you.

Validate in CI, not just once

Add a check that fails the build if JSON-LD is missing or doesn't parse:

// scripts/check-jsonld.mjs
import { readFileSync } from "node:fs";
import { globSync } from "glob";

let failed = 0;
for (const file of globSync("out/**/*.html")) {
  const html = readFileSync(file, "utf8");
  const blocks = [...html.matchAll(/<script type="application\/ld\+json">([\s\S]*?)<\/script>/g)];
  for (const [, raw] of blocks) {
    try {
      const data = JSON.parse(raw);
      if (!data["@context"] || !data["@type"]) throw new Error("missing @context/@type");
    } catch (e) {
      console.error(`${file}: invalid JSON-LD – ${e.message}`);
      failed++;
    }
  }
}
process.exit(failed ? 1 : 0);

This catches syntax problems. It doesn't catch semantic ones (wrong property names, missing required fields for a rich result), so also run key templates through the Schema.org validator and Google's Rich Results Test after template changes.

Common mistakes

• Markup for content that isn't on the page (reviews nobody can see, FAQs hidden from users). This violates Google's structured data guidelines.
• Self-serving review stars on your own organisation or product. Google doesn't show these for the entity itself.
• Stale dateModified, or bumping it on every deploy without changing content.
• AI-generated JSON-LD nobody checked. Google's guidance on AI content explicitly says to review structured data generated by AI. Hallucinated prices and fake sameAs URLs are common.
• Multiple conflicting Organization blocks from different plugins.

Checking how AI engines read the result

Structured data is one input into how engines understand a page. To see the whole picture (crawlability, extraction, schema, trust signals) and how it compares with competitors' pages, Vista AI's Page Audit scores a URL on AI Visibility, AI Understanding and AI Citation, including a schema check, and lists prioritised fixes.

Key takeaways

• No special "AI schema" exists or is required. Standard JSON-LD still helps engines read your facts.
• Prioritise Organization, Article/TechArticle, Product/SoftwareApplication with offers, and BreadcrumbList.
• FAQ and HowTo rich results are mostly gone. Don't build for them.
• Generate JSON-LD from the same data as the visible page, render it server-side, and validate in CI.

The good news: about 80% of the work is classic technical SEO. The other 20% is where AI search behaves differently, mainly bot access, JavaScript rendering and passage structure.

Here are 25 checks, grouped by stage, each with a way to verify it in under a minute.

Crawl access (1–6)

1. robots.txt allows the crawlers you want. Separate decisions for training bots and search/retrieval bots:

curl -s https://example.com/robots.txt

Look for GPTBot, ClaudeBot (training), OAI-SearchBot, Claude-SearchBot, PerplexityBot (search indexing) and ChatGPT-User, Claude-User, Perplexity-User (live user-triggered fetches). Blocking search bots removes you from those engines' answers.

2. Google-Extended decision is deliberate. It controls Gemini training and some grounding uses. It does not affect Google Search or AI Overviews, so blocking it won't hide you from AI Overviews, and allowing it won't get you in.

3. CDN/WAF isn't blocking AI bots. Bot-protection defaults on some CDNs block AI crawlers regardless of robots.txt. Check firewall events for those user agents and look for 403 or challenge responses:

grep -E "GPTBot|OAI-SearchBot|ChatGPT-User|PerplexityBot|ClaudeBot|Claude-User" access.log \
  | awk '{print $9}' | sort | uniq -c

4. Rate limits don't punish live fetches.429 responses to *-User agents mean a real person's conversation failed to load your page.

5. No accidental noindex.

curl -sI https://example.com/page | grep -i x-robots-tag
curl -s https://example.com/page | grep -i '<meta name="robots"'

6. XML sitemap is complete and submitted. Include every canonical URL you want indexed, with accurate <lastmod> dates. Submit it in Google Search Console and Bing Webmaster Tools. Bing matters more than people expect: some AI products draw on Bing's index.

Rendering (7–10)

7. Main content is in the raw HTML. The single most important AI-specific check. Googlebot renders JavaScript; many AI fetchers don't reliably.

curl -s https://example.com/pricing | grep -c "per month"

Zero matches for text you can see in the browser means it's client-rendered.

8. Content pages use SSR or static generation. In Next.js App Router, Server Components render on the server by default. The usual mistake is a "use client" page that fetches content in useEffect. Astro, Hugo, Eleventy and most static site generators are fine out of the box.

9. Hidden content is in the DOM. Tabs, accordions and "read more" sections should render their text in HTML and hide it with CSS, not fetch it on click.

10. Rendered HTML in Google matches expectations. Search Console → URL Inspection → Test live URL → View tested page. Search the HTML for your key sentences.

Indexing and canonicals (11–15)

11. One canonical per piece of content.

curl -s https://example.com/blog/post | grep -i 'rel="canonical"'

12. Cross-posted content points home. If you publish on your blog and syndicate to Hashnode, dev.to or Medium, every copy should carry a canonical URL pointing to the original.

13. Google picked the canonical you intended. URL Inspection → "Google-selected canonical". If it differs from yours, investigate duplicates.

14. No thin or near-duplicate pages at scale. Tag pages, empty category pages and auto-generated variants dilute your site. Mass-produced low-value pages can also fall under Google's scaled content abuse policy.

15. Snippets aren't restricted by accident.nosnippet or a tiny max-snippet prevents your page from being a supporting link in AI Overviews. Use data-nosnippet on specific elements if you need to protect fragments.

Structured data (16–19)

16. Organization (or Person) markup on the homepage, with name, url, logo and sameAs links to your official profiles. This helps engines tie mentions of your brand to your site.

17. Article / BlogPosting markup on posts, with headline, author, datePublished and dateModified.

18. Product / SoftwareApplication markup with offers on product and pricing pages, matching the visible prices exactly.

19. It validates and matches the page. Run it through the Schema.org validator and Google's Rich Results Test. JSON-LD that contradicts the visible page is worse than none.

(The next post in this series goes deeper on JSON-LD.)

Content structure for passages (20–23)

AI search retrieves and quotes passages, not whole pages. These checks are about making good passages exist.

20. Headings are questions or specific statements. "How much does it cost for a team of 10?" beats "Pricing".

21. Answer first. The first one or two sentences under each heading directly answer it.

22. Sections stand alone. No "as mentioned above" or "it" at the start of a section. Repeat the subject.

23. Comparisons are in tables. Tables chunk cleanly and get quoted accurately.

Performance and trust (24–25)

24. Core Web Vitals pass on mobile. LCP, INP and CLS in Search Console's Core Web Vitals report or PageSpeed Insights. Slow servers also time out impatient AI fetchers.

25. Authorship and freshness are visible. Named author with a short bio, visible publish and update dates, an About page and real contact details.

About llms.txt

You'll see llms.txt recommended in many GEO checklists. It's a proposed Markdown file at your site root that points LLMs to key pages. It can help some coding assistants and agents working with documentation. Google has said it doesn't use it for Search, and no major AI search engine has confirmed relying on it for citations. It's fine to add if it's cheap; just don't count it as one of your 25.

Run it as a script

Checks 1, 5, 7, 11 and 15 can be automated in a few lines:

#!/usr/bin/env bash
# usage: ./ai-seo-check.sh https://example.com/pricing "per month"
URL=$1; PHRASE=$2
ORIGIN=$(echo "$URL" | awk -F/ '{print $1"//"$3}')

echo "== robots.txt AI rules"
curl -s "$ORIGIN/robots.txt" | grep -iE -A2 "GPTBot|OAI-SearchBot|ClaudeBot|Claude-SearchBot|PerplexityBot|Google-Extended" || echo "(no AI-specific rules)"

HTML=$(curl -s -A "Mozilla/5.0 (compatible; seo-check)" "$URL")
echo "== meta robots";      echo "$HTML" | grep -io '<meta name="robots"[^>]*>' || echo "(none)"
echo "== X-Robots-Tag";     curl -sI "$URL" | grep -i x-robots-tag || echo "(none)"
echo "== canonical";        echo "$HTML" | grep -io '<link rel="canonical"[^>]*>' || echo "MISSING"
echo "== phrase in raw HTML"; echo "$HTML" | grep -qi "$PHRASE" && echo "found" || echo "NOT FOUND (client-rendered?)"
echo "== JSON-LD blocks";   echo "$HTML" | grep -c 'application/ld+json'

Going further

This checklist covers the technical floor. The next layer, whether AI engines actually understand and cite the page, needs a different kind of audit.

Vista AI's Page Audit covers both. It checks seven areas (traditional SEO signals, AI crawlability and rendering, schema, AI content extraction, E-E-A-T signals, link quality and citation potential) and returns 0–100 scores for AI Visibility, AI Understanding and AI Citation, with a prioritised fix list and side-by-side scoring of competitor pages.

This post separates them, shows how each works (with code), and covers what they mean for anyone publishing on the web.

The three things people call "watermarking"

They're complementary. Watermarks survive when metadata is stripped. Manifests carry a verifiable history when they survive. Labels are simple and widely supported, but trivially removed.

1. Statistical watermarks: SynthID

SynthID is Google DeepMind's watermarking technology. It's applied to content generated by Google's models (Gemini text, Imagen images, Veo video, Lyria audio) and some partner tools.

How text watermarking works

A language model picks each next token by sampling from a probability distribution. SynthID Text nudges that sampling using a secret key:

1. For each step, a pseudorandom function scores candidate tokens using the watermarking keys and the previous few tokens (the n-gram context).

2. Sampling is biased toward tokens with high scores, in a way designed not to noticeably change quality.

3. A detector holding the same keys recomputes those scores over a piece of text. Watermarked text has statistically higher scores than chance; unwatermarked text doesn't.

The text implementation is open source. Google released it in October 2024, and it's built into Hugging Face Transformers. You can watermark output from your own open model like this:

from transformers import AutoModelForCausalLM, AutoTokenizer, SynthIDTextWatermarkingConfig

tokenizer = AutoTokenizer.from_pretrained("google/gemma-2-2b", padding_side="left")
model = AutoModelForCausalLM.from_pretrained("google/gemma-2-2b")

watermarking_config = SynthIDTextWatermarkingConfig(
    keys=[654, 400, 836, 123, 340, 443, 597, 160, 57],  # keep your real keys secret
    ngram_len=5,
)

inputs = tokenizer(["Write a short intro to Postgres indexing."], return_tensors="pt", padding=True)
out = model.generate(**inputs, watermarking_config=watermarking_config,
                     do_sample=True, max_new_tokens=200)
print(tokenizer.batch_decode(out, skip_special_tokens=True)[0])

Detection uses SynthIDTextWatermarkDetector with a BayesianDetectorModel that you train for your specific keys (Hugging Face's synthid_text research project has the training script):

from transformers import (AutoTokenizer, BayesianDetectorModel,
                          SynthIDTextWatermarkLogitsProcessor, SynthIDTextWatermarkDetector)

detector_model = BayesianDetectorModel.from_pretrained("your-org/your-trained-detector")
processor = SynthIDTextWatermarkLogitsProcessor(**detector_model.config.watermarking_config, device="cpu")
tokenizer = AutoTokenizer.from_pretrained(detector_model.config.model_name)
detector = SynthIDTextWatermarkDetector(detector_model, processor, tokenizer)

score = detector(tokenizer(["text to check"], return_tensors="pt").input_ids)

Three consequences fall straight out of this design:

• You can only detect watermarks whose keys you have. Open-sourcing the method doesn't let anyone detect Gemini's watermark. Google's own SynthID Detector portal has been limited-access (journalists, researchers, media professionals).

• Short text is hard. Detection is statistical, so a tweet-length snippet gives weak evidence. Longer passages give stronger evidence.

• Heavy editing weakens it. Paraphrasing, translation and substantial rewriting reduce the signal. Light edits usually don't erase it completely.

Image, video and audio

SynthID for images, video and audio embeds the signal in the pixels or waveform. It's designed to survive common edits like cropping, resizing, compression and colour adjustments. Unlike the text version, these watermarks are proprietary, and only Google's tools can check them.

In May 2026 Google announced SynthID verification in Search (you can ask Lens, AI Mode or Circle to Search whether an image was made with AI), with Chrome support rolling out afterwards.

2. Provenance manifests: C2PA Content Credentials

C2PA (Coalition for Content Provenance and Authenticity) is an open standard backed by Adobe, Microsoft, Google, OpenAI and others. It isn't a watermark. It's a cryptographically signed record of where a file came from and what was done to it, embedded in the file (for JPEG/PNG, in a JUMBF metadata box).

A manifest contains assertions ("created by model X", "cropped", "colour-adjusted") signed with the creator's certificate. If anyone edits the file without updating the manifest, the signature check fails.

You can inspect and sign manifests with the open-source c2patool CLI:

# Inspect an image's Content Credentials
c2patool photo.jpg

# Add a manifest (manifest.json describes the assertions; signing cert configured inside)
c2patool photo.jpg -m manifest.json -o photo-signed.jpg

A minimal manifest marking an image as AI-generated looks like this:

{
  "claim_generator": "my-pipeline/1.0",
  "assertions": [
    {
      "label": "c2pa.actions",
      "data": {
        "actions": [
          {
            "action": "c2pa.created",
            "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia"
          }
        ]
      }
    }
  ]
}

The weakness is obvious to anyone who has run an image pipeline: metadata gets stripped. Many image optimisers, CMS upload flows, CDNs and social platforms remove it by default. If you publish C2PA-signed images, check that your pipeline preserves them. Some CDNs, including Cloudflare, have added an option to preserve Content Credentials through image transformations.

Google has said C2PA verification is coming to Search and Chrome, following its rollout in the Gemini app in May 2026.

3. Metadata labels: IPTC DigitalSourceType

The simplest layer. IPTC Photo Metadata has a DigitalSourceType field with a controlled vocabulary. The value for fully AI-generated media is:

http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia

(There are related values, such as compositeWithTrainedAlgorithmicMedia for images that combine AI and other elements.)

Set it with exiftool:

exiftool -XMP-iptcExt:DigitalSourceType="http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia" hero.png

# Verify
exiftool -XMP-iptcExt:DigitalSourceType hero.png

This one has direct commercial consequences. Google Merchant Center requires AI-generated product images to carry this IPTC value, and Google's "About this image" feature reads IPTC and C2PA metadata to show users how an image was made.

What this means for SEO and AI search

Let's answer the questions people actually ask:

"Will Google demote my post if it detects a SynthID watermark?" Google hasn't said that watermarks are a ranking signal. Its guidance on AI content focuses on quality and scaled content abuse, not on how content was produced. Its 2026 SynthID and C2PA announcements were about verification for users, with no mention of ranking.

"Should I strip metadata to hide that an image is AI-generated?" For Merchant Center product images, no: labelling is required. For editorial images, removing provenance doesn't help rankings, and it removes context that platforms increasingly show to users. Being upfront also matches Google's advice to explain how content was made where readers would expect it.

"Does watermarked text get cited less by ChatGPT or Perplexity?" There's no public evidence that AI search engines check text watermarks when choosing sources. What they demonstrably favour is specific, original, well-structured content, whoever wrote it.

"Can I prove my content is original with watermarks?" Partially. C2PA can show that your signed image came from your pipeline. For text, there's no widely adopted provenance standard yet, so dates, bylines, canonical URLs and being the first indexed source remain your best evidence.

A practical policy for a dev blog or product site

1. AI-generated images: set IPTC DigitalSourceType, and keep metadata through your image pipeline.

2. Product images in Merchant Center: IPTC labelling is mandatory for AI-generated ones.

3. Signed provenance: if your images are likely to be reused or questioned (news, product photos, brand assets), add C2PA manifests and confirm your CDN preserves them.

4. Text: don't worry about watermarks. Worry about accuracy and originality.

5. Disclosure: add a short note on how content was made where readers would want it.

Watching how AI uses your content

Watermarks track where content came from. The more pressing question for most sites is where their content ends up: which AI answers quote it, and whether they describe the product correctly.

Vista AI's AI Citation Tracking monitors that side. It captures the prompt, full response and cited source each time an AI engine mentions your brand, scores sentiment, tracks brand-name variations and flags inaccurate claims.

Key takeaways

• Watermark (SynthID): statistical signal inside the content. Robust to metadata stripping, only detectable with the right keys.

• Manifest (C2PA): signed history attached to the file. Verifiable, but lost if metadata is stripped.

• Label (IPTC): a simple metadata field. Required for AI product images in Merchant Center.

• None of them is a confirmed ranking factor. Quality and accuracy are.

That's good news for developers. It means AI visibility in Google is mostly a technical problem you can debug with tools you already have. This post walks through the pipeline step by step, shows where pages fall out, and covers the controls you have over how much Google's AI can use.

What Google says (and doesn't say)

Google's documentation on AI features is short and direct:

• There are no additional requirements to appear in AI Overviews or AI Mode, and no special optimizations are necessary.

• To be shown as a supporting link, a page must be indexed and eligible to be shown in Google Search with a snippet.

• No special schema, machine-readable file or AI-specific markup is required.

• AI Overviews and AI Mode use query fan-out: issuing multiple related searches across subtopics to develop a response.

• Traffic from AI features is included in Search Console's Performance report under the "Web" search type. It isn't broken out separately.

So the question "how does Google see my content for AI?" is really "how does Google see my content, full stop?", plus one extra filter: snippet eligibility.

The pipeline

URL discovered (links, sitemap)
        │
        ▼
1. Crawl ─────────── robots.txt allows Googlebot? Server returns 200?
        │
        ▼
2. Render ────────── Web Rendering Service runs JavaScript (evergreen Chromium)
        │
        ▼
3. Index ─────────── canonical chosen, content stored, noindex respected
        │
        ▼
4. Snippet eligible? ─ nosnippet / max-snippet / data-nosnippet respected
        │
        ▼
5. Retrieved for a query or fan-out sub-query, then quoted by the AI system

Let's go through where things break.

1. Crawling

Google's AI features use Googlebot, the same crawler as Search. That has a practical consequence that confuses people:

Blocking Google-Extended in robots.txt does not remove you from AI Overviews or AI Mode.

Google-Extended is a control token for whether your content can be used to train Gemini models and for some grounding uses outside Search. It doesn't affect Search. The only way to keep content out of Google's AI features via robots rules is to restrict Googlebot itself, which also removes it from normal Search.

Debug it: Search Console → URL Inspection → "Crawl allowed?" and "Page fetch".

2. Rendering

Googlebot renders pages with an up-to-date Chromium, so client-side JavaScript content usually gets indexed. "Usually" is doing a lot of work there:

• Rendering can be deferred, so JS-dependent content is indexed later than server-rendered HTML.

• Content loaded only after user interaction (click to expand, infinite scroll without paginated URLs) may never be seen.

• Blocked JS/CSS resources, failed API calls during render, or timeouts produce a partial page.

Debug it: URL Inspection → "Test live URL" → "View tested page" → HTML tab. Search the rendered HTML for a sentence from your main content. If it's not there, Google can't quote it.

Worth knowing: other AI search engines' crawlers are generally less capable at rendering than Googlebot. Server-side rendering or static generation for content pages fixes the problem for all of them at once.

3. Indexing and canonicals

A page that isn't indexed can't be a supporting link. The common silent failures:

• Wrong canonical. Google picked a different URL as canonical (check "Google-selected canonical" in URL Inspection). Cross-posted articles are a classic case: your Hashnode post, your dev.to copy and your company blog copy compete, and Google may pick the one you didn't intend.

• Duplicate or thin variants consolidated into another URL.

• noindex left over from staging.

• "Crawled – currently not indexed", which often means Google didn't see enough value to index the page.

Debug it: Search Console → Pages report, and the "Google-selected canonical" field.

4. Snippet eligibility: your control panel for AI use

This is the AI-specific layer. Google applies the same preview controls to AI Overviews and AI Mode as to classic snippets. You can use them to limit what the AI can show from your page without removing the page from Search.

Page level, meta robots:

<!-- No text snippet at all. Also blocks use as a supporting link in AI features. -->
<meta name="robots" content="nosnippet">

<!-- Limit snippet text to 50 characters -->
<meta name="robots" content="max-snippet:50">

Or as an HTTP header (useful for PDFs and other non-HTML files):

location ~* \.pdf$ {
    add_header X-Robots-Tag "nosnippet";
}

Section level, data-nosnippet: exclude specific parts of a page while keeping the rest eligible.

<p>Acme Analytics costs $49 per month on the Starter plan.</p>

<div data-nosnippet>
  <p>Internal benchmark details that we don't want quoted out of context.</p>
</div>

data-nosnippet works on span, div and section elements. Use it carefully: content inside it can't be quoted, which also means it can't help you get cited.

A trade-off worth stating plainly: every restriction you add reduces the chance of being used as a source. nosnippet on a page means it can't appear as a supporting link in AI features at all. Most sites that want AI visibility should leave snippets unrestricted and use data-nosnippet only for genuinely sensitive fragments.

5. Retrieval and query fan-out

Once a page is indexed and snippet-eligible, it competes on relevance like any search result, with one twist. Because of fan-out, the AI system doesn't just run the user's query. It runs related sub-queries.

Example: "Is Supabase good for a production SaaS?" might fan out into sub-queries about Supabase pricing at scale, row-level security, backup policies, connection pooling limits, and alternatives.

Practical implications:

• Narrow, specific pages get pulled in. A precise post on "Supabase connection pooling limits on the Pro plan" can become a supporting link for a broad question.

• Clear sub-topic headings help. A post structured as a set of specific questions maps well onto fan-out sub-queries.

• Passages need to stand alone. The AI quotes a passage, not your whole argument.

How Google treats AI-written pages in this pipeline

Nothing in the pipeline above checks whether a human wrote your page. Google's position is that the method of creation isn't the issue: quality is, and producing many low-value pages at scale violates its spam policies regardless of method. (The previous post in this series covers that policy in detail.)

Where AI-written content does run into trouble in this pipeline is earlier and more mundane: thin pages don't get indexed ("Crawled – currently not indexed"), near-duplicates get folded into other canonicals, and generic passages lose to specific ones at retrieval.

A 15-minute debug routine for one page

1. URL Inspection → Coverage: indexed? Which canonical did Google pick?

2. Test live URL → View tested page → HTML: is your key sentence in the rendered HTML?

3. View source (raw HTML): is it there without JavaScript? (Matters for non-Google AI engines.)

4. Check meta robots and X-Robots-Tag: any nosnippet or max-snippet you didn't intend?

5. Search site:yourdomain.com "exact sentence": does Google return the page?

6. Performance report: filter by page and look at queries. Long, question-like queries are often where AI features show up.

Beyond Google

Passing all of this gets you eligible in Google's AI features. ChatGPT, Perplexity, Claude and Copilot have their own crawlers, indexes and rendering limits, so a page can be fine in Google and invisible elsewhere.

Vista AI's Page Audit checks a page against both sides: traditional SEO signals and AI crawlability, rendering, schema, content extraction and citation potential. It returns 0–100 scores for AI Visibility, AI Understanding and AI Citation, plus a prioritised fix list, and can score competitor pages side by side.

Key takeaways

• Google's AI features use the normal Search pipeline. Indexed + snippet-eligible is the bar.

• Google-Extended does not control AI Overviews. Snippet controls do.

• Use data-nosnippet for fragments, not nosnippet for whole pages, if you want AI visibility.

• Query fan-out rewards specific, well-structured pages.

• Debug with URL Inspection's rendered HTML, not with what you see in your browser.

But "out of the box" stops short of a few decisions only you can make, and those decisions now affect two audiences: Google, and the AI assistants (ChatGPT, Perplexity, Google's AI Overviews) that increasingly answer developer questions by quoting blog posts.

This guide covers the setup, the per-post fields, cross-posting without losing credit, and how to structure posts so they get quoted.

Part 1: Blog-level setup (do this once)

Use a custom domain

A custom domain (blog.yourname.dev instead of yourname.hashnode.dev) means the authority your posts build accrues to a domain you own and can take elsewhere. If you ever move platforms, you redirect your own domain and keep your rankings.

Hashnode supports custom domains and subdomains; the exact plan requirements have changed over time, so check your blog's domain settings for what's currently included.

Verify the blog in Google Search Console and Bing Webmaster Tools

1. Add your blog domain as a property in Google Search Console.

2. Submit your sitemap. Hashnode generates it automatically at:

https://your-blog-domain/sitemap.xml

1. Do the same in Bing Webmaster Tools. Some AI products draw on Bing's index, so being indexed there matters more than its search market share suggests.

Fill in the blog's own metadata

Give the blog a clear name and description that say what you write about ("Notes on Postgres performance and backend architecture", not "My thoughts"). That description becomes context for how search engines and AI systems categorise your blog.

Write a real About page

A short bio with your role, what you build and links to your GitHub and LinkedIn. It's a trust signal for readers, Google's quality systems and AI answer engines deciding whose explanation to quote.

Part 2: Per-post SEO fields

Hashnode's editor exposes the fields that matter. Use them on every post.

Two rules:

• Don't change slugs after publishing unless you set up a redirect. Hashnode posts get backlinks quickly, and a broken URL loses them.

• Write the SEO description yourself. Auto-generated descriptions often start with your intro anecdote, which is the least informative part of the post.

Part 3: Cross-posting without losing credit

Many developers publish the same article on Hashnode, dev.to, Medium and a company blog. Without canonical URLs, those copies compete with each other, and Google may pick a copy you didn't intend as the "original".

The rule: pick one home for each article, and point every other copy at it.

• If Hashnode is the original: publish there first. On dev.to, set canonical_url in the front matter to the Hashnode URL. On Medium, use "Import a story" (which sets the canonical) or set it in the story settings.

• If another site is the original: in Hashnode's article settings, mark the post as republished and enter the original URL. Hashnode then outputs a canonical link to it.

Check it worked:

curl -s https://your-blog-domain/your-post | grep -io '<link rel="canonical"[^>]*>'

Then, a week or so after publishing, check Google Search Console → URL Inspection on the original. "Google-selected canonical" should match the URL you chose.

Canonicals are a hint, not a command. Publishing the original first, a few days before the copies, makes it more likely that search engines treat it as the source.

Part 4: Write posts that get cited by AI

AI search answers developer questions by retrieving passages from pages and quoting the clearest ones. Hashnode posts are well placed for this: they're server-rendered (so AI crawlers can read them without running JavaScript) and developers tend to write specific, practical content. A few structural habits make a big difference.

Make headings match questions

<!-- Weak -->
## The fix

<!-- Strong -->
## How to fix N+1 queries in Prisma with include

AI systems often break a user's question into sub-questions. A heading that matches one of them makes your section the obvious passage to retrieve.

Answer in the first two sentences

Under each heading, state the answer, then explain it:

## Why is my Prisma query slow inside a loop?

Calling `findUnique` inside a loop sends one query per item: the N+1 problem.
For 100 users, that's 101 round-trips instead of 1 or 2.

Here's what it looks like in practice…

Make every section stand on its own

Avoid starting sections with "This", "It" or "As we saw above". The retriever may hand the model your section with nothing around it.

Include something only you have

The output of your benchmark. The exact error message you hit. Timings before and after. Version numbers. This is the information gain that makes an AI system prefer your post over the twenty generic ones covering the same topic. It's also what makes a post useful to humans.

Put comparisons in tables

"Prisma vs Drizzle vs Kysely" as a table with real criteria gets quoted far more cleanly than three paragraphs of prose.

Date your claims

"As of Prisma 6.x" or "tested on Node 22" helps readers, and helps AI systems judge whether your answer is current.

Part 5: Check whether it's working

Google: Search Console's Performance report shows queries, clicks and positions. AI Overview traffic is included in the "Web" totals; it isn't broken out separately. Long, question-shaped queries in your report are often where AI features show up.

AI assistants: traffic from ChatGPT, Perplexity, Gemini and Copilot shows up as referrals in your analytics, if you have analytics on a custom domain. ChatGPT also often adds utm_source=chatgpt.com to links.

Being cited, not just visited: many AI answers cite a source without the user clicking. To see whether your posts are being cited, and for which questions, you need to query the AI engines directly and repeatedly. Vista AI's AI Citation Tracking does this across the major engines and records the prompt, full answer and cited URL for each mention, so you can see which of your posts AI systems rely on and what they say about them.

The checklist

• Custom domain connected

• Blog verified in Google Search Console and Bing Webmaster Tools, sitemap submitted

• Blog description and About page say who you are and what you write about

• Every post: SEO title, SEO description, clean slug, 3–5 tags, OG image

• Cross-posts point to one canonical original

• Headings phrased as questions or specific statements

• Each section answers first and stands alone

• Every post includes something first-hand: output, numbers, versions

Both are wrong. Google has published fairly specific guidance, and it's more useful than either extreme. This post goes through what it says, what it doesn't, and how to use AI in a writing workflow without creating risk.

The short answer

No, Google does not penalize content for being AI-generated. It penalizes content that is low-value and produced at scale to manipulate rankings, regardless of whether a human, a model or a template produced it.

Google has said this since February 2023, when it published "Google Search's guidance about AI-generated content". The framing was about rewarding high-quality content however it is produced. The current documentation, "Google Search's guidance on using generative AI content on your website", keeps the same position and adds practical rules.

The policy that actually matters: scaled content abuse

The rule you can break is Google's spam policy on scaled content abuse, introduced with the March 2024 core update. Google's generative AI guidance points straight at it:

"Using generative AI tools or other similar tools to generate many pages without adding value for users may violate Google's spam policy on scaled content abuse."

The key words are many pages and without adding value. The policy targets patterns like:

• generating hundreds of pages from a keyword list with little or no editing,

• scraping or rewording other sites' content (including by automated synonym swapping or translation),

• stitching together content from multiple pages without adding anything,

• publishing pages that make little sense to a reader but contain search keywords.

None of this is specific to AI. A content farm of underpaid writers producing the same output would violate the same policy. AI just made it cheap.

Google enforces this algorithmically (through core and spam updates) and with manual actions, which you'll see in Search Console under Security & Manual Actions.

What Google asks you to do with AI content

The generative AI guidance has a few concrete requirements that are easy to miss.

1. Fact-check everything, including metadata

Google says it's "critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing". It's explicit that this covers more than body text:

• <title> tags and meta descriptions

• structured data (JSON-LD)

• image alt text

That last group is where AI-generated errors hide, because nobody reads them. A hallucinated "price": "29" in your JSON-LD is still wrong data, and it can show up in search features.

2. Consider explaining how content was made

Google suggests adding information about how content was created "in a way that makes sense for your audience". For a developer blog, that might be a line like "Drafted with AI assistance; code tested by the author on Node 22". It's not mandatory for Search, but it supports trust. Some platforms, including several developer blogging communities, have their own disclosure rules that are stricter.

3. E-commerce has hard labelling rules

If you sell through Google Merchant Center:

• AI-generated images must carry IPTC DigitalSourceType metadata set to TrainedAlgorithmicMedia.

• AI-generated product data (titles, descriptions) must be specified separately and labelled as AI-generated.

(The post on content watermarking in this series covers how that metadata works.)

4. Structured data rules still apply

AI-written JSON-LD has to follow the same structured data guidelines as hand-written markup, and must match visible page content.

"But can Google detect AI content?"

This is the wrong question, and it's worth explaining why.

Google hasn't announced a ranking system that classifies text as AI-written and demotes it. It doesn't need one. Its systems evaluate whether content is helpful, original, accurate and trustworthy. Mass-produced, unedited AI output tends to fail those tests on its own:

• it repeats what's already ranking (no information gain),

• it's generic (no first-hand experience),

• it contains errors (low trust),

• it's published in suspicious volume (a spam signal).

Text watermarks like Google's SynthID exist, but they only work on output from models that embed them, they can weaken under heavy editing, and Google hasn't said it uses them as a ranking signal. Optimising your workflow to "avoid AI detection" solves a problem you don't have, while ignoring the quality problem you might.

Google's "Who, How, and Why" test

Google's helpful content documentation offers a simple self-check that maps neatly onto AI use:

• Who created the content? Is it clear, with a byline and background?

• How was it created? Would readers expect to know about automation, and would disclosure help them?

• Why was it created? Primarily to help people, or primarily to attract search traffic?

If the honest answer to "why" is "we generated 300 pages because the keywords had volume", the method doesn't matter. That's the pattern the spam policy describes.

A safe AI writing workflow for a developer blog

Here's a workflow that uses AI heavily and stays well within the guidelines:

1. You pick the topic from real experience: a bug you fixed, a migration you did, a benchmark you ran.

2. AI helps outline and draft the explanatory parts.

3. You add what the model can't know: your numbers, your error messages, your decisions and why.

4. You run every code sample. Paste the actual output.

5. You fact-check every claim, especially versions, API names, prices and limits. These are exactly where models hallucinate.

6. You review metadata: title, description, alt text, JSON-LD.

7. You publish at a human pace. One excellent post beats twenty generated ones.

Steps 3 and 4 are what make a post worth citing, by Google and by AI answer engines.

Quick checklist

• Each post contains something first-hand: data, code output, experience

• Every fact, version number and API name has been checked

• Title, meta description, alt text and JSON-LD reviewed by a human

• Author byline and date are visible

• Publishing volume reflects real editorial capacity

• No pages that exist only to target a keyword variation

Where AI search fits in

The same qualities that keep AI-assisted content safe in Google (originality, accuracy, specifics) are what get content cited in ChatGPT, Perplexity and Google's AI Overviews. Generic pages don't just risk spam filters. They're also the pages AI answers have no reason to quote.

Generative Engine Optimization (GEO) is the practice of making your content more likely to be used and cited in those generated answers. You'll also see it called AEO (Answer Engine Optimization) or LLMO. The names differ; the problem is the same.

This guide skips the hype and explains GEO the way developers like things explained: what the system does, where your page enters it, and which parts you can actually influence.

SEO vs. GEO in one table

They overlap heavily. Google says plainly that there are no special requirements for its AI features beyond normal SEO: a page has to be indexed and eligible to show a snippet. But GEO adds two layers on top: passage-level retrieval and the model's own judgement about what to say.

How an AI search answer gets built

Most AI search systems follow some version of retrieval-augmented generation (RAG):

user question
   │
   ▼
1. Query rewriting / fan-out  ──►  several sub-queries
   │
   ▼
2. Retrieval  ──►  candidate pages from a search index (Google's, Bing's, or the engine's own)
   │
   ▼
3. Chunking + ranking  ──►  the best few passages
   │
   ▼
4. Generation  ──►  the model writes an answer from those passages + what it already knows
   │
   ▼
5. Attribution  ──►  some passages get shown as citations

Google describes step 1 directly: AI Overviews and AI Mode use a "query fan-out" technique, issuing multiple related searches across subtopics to build a response. That matters for content strategy. A single question like "best Postgres hosting for a side project" may fan out into sub-queries about pricing, free tiers, connection limits and backups. A page that answers one of those sub-questions cleanly can get cited even if it would never rank for the original query.

Where your page can win or lose

Each stage has its own failure modes. This is the useful mental model for GEO work:

Stage 2: Retrieval (can the engine find and read the page?)

• Blocked crawlers. ChatGPT search, Claude and Perplexity use their own bots (OAI-SearchBot, Claude-SearchBot, PerplexityBot, plus user-triggered agents like ChatGPT-User). A robots.txt rule or CDN bot setting can silently remove you from those engines.

• Content that needs JavaScript. Googlebot renders JavaScript. Many AI fetchers don't do it reliably. If your content only exists after hydration, some engines see an empty page.

• Not indexed. For Google's AI features, a page that isn't indexed, or is blocked from snippets, can't be a supporting link.

Stage 3: Chunking and ranking (does a good passage exist?)

• The answer to the question is buried in paragraph nine.

• Headings like "Overview" or "Our approach" give the retriever nothing to match.

• Sections start with "It" or "As mentioned above", so the chunk makes no sense on its own.

Stage 4: Generation (does the model want to use you?)

• Your page says what fifty other pages say. There's no reason to prefer it.

• Third-party sources (reviews, forums, comparison posts) describe you differently than you describe yourself, and the model trusts them more.

• Facts conflict across your own pages (old pricing on one, new on another).

Stage 5: Attribution (do you get the link?)

• You can be mentioned without being cited: the model knows your brand but sources its claims from a review site.

• You can be cited without being mentioned: your blog post supported a general claim, but the answer recommends someone else.

These are separate outcomes and should be measured separately.

The technical GEO checklist

Most of GEO is good technical SEO plus writing for passages. Here's the short version, in order of impact:

1. Let the right bots in. Decide per bot type rather than blanket-blocking "AI":

# Allow AI search / retrieval bots (they fetch pages to answer live questions)
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Allow: /

# Optionally block model-training crawlers
User-agent: GPTBot
User-agent: ClaudeBot
Disallow: /

Then check your CDN/WAF, which can override robots.txt entirely.

2. Server-render content pages. If curl https://yoursite.com/pricing | grep "per month" returns nothing, neither will a non-rendering crawler.

3. Answer first, under question-shaped headings. Each H2/H3 should be a question your reader asks, followed by a one or two sentence answer, then the detail.

4. Make sections self-contained. Repeat the subject ("Acme's free tier includes…") instead of "It includes…". Each chunk may be the only thing the model sees.

5. Add specifics nobody else has. Benchmarks you ran, numbers from your own data, a comparison table, a worked example. Original information is the strongest reason for a model to cite you over a generic page.

6. Keep facts consistent. Same price, same feature list, same product description across your site, docs, and structured data.

7. Show who wrote it and when. Named author, short bio, published and updated dates.

Things that are mostly myths (for now)

• "You need a special AI schema." Google explicitly says no special schema or AI-specific markup is required for AI Overviews. Normal structured data still helps machines read your facts.

• "llms.txt gets you into ChatGPT." It's a proposed convention, useful for some agents and documentation tools. No major AI search engine has confirmed using it for ranking or citation, and Google has said it doesn't use it.

• "Keyword density for prompts." LLMs work on meaning, not repeated phrases. Stuffing makes passages worse, not better.

How to measure GEO

This is where GEO really differs from SEO. AI answers are non-deterministic: the same prompt can return different brands on different runs, in different engines, for different users. A screenshot is a sample of one.

A workable measurement setup:

1. Write 20–50 prompts the way your users actually ask questions.

2. Run each prompt repeatedly, across several engines, on a schedule.

3. Record for each answer: mentioned? position in the list? cited? how described?

4. Report rates over time (e.g. "mentioned in 34% of ChatGPT answers this month, up from 21%"), not single results.

5. Track 2–5 competitors on the same prompts, because visibility only means something relative to who's recommended instead.

You can script this against the OpenAI and Perplexity APIs. Doing it daily across ChatGPT, Gemini, Claude, Perplexity, Copilot and Google AI Mode is where a dedicated tool earns its keep. Vista AI's AI Rank Tracker is built for this: it runs your prompt set daily across those engines, rolls results into a 0–100 visibility index, groups prompts by buyer intent and flags "quick win" prompts where you're close to being recommended.

Key takeaways

• GEO = getting used and cited in AI-generated answers, not just ranked.

• The competitive unit is the passage, so structure matters as much as topic.

• Technical blockers (bots, JavaScript, indexing) remove you before quality even counts.

• Measure rates across many runs and engines, never single screenshots.

• There's no secret AI markup. Clear, specific, well-structured, crawlable content wins in both SEO and GEO.