Page family SEO/GEO audit

A five-pass review of every page one template produces — a set of service pages, tool pages or product pages — asking two questions: can a search engine index them, and can an AI answer engine lift a passage and attribute it to you? It reads the deployed HTML rather than the source, because the markdown converters behind most fetch tools strip the structured data out and a page with correct markup then reads as having none. It grades each page against a written rubric, checks whether a machine can tell the page and the organization are the same business, tests whether individual passages stand alone well enough to be quoted, and looks for the template seams nobody checks. Findings come back worst-first with the file that would fix each one. Generative engine optimization, nothing to do with geography. It changes nothing and emits no score out of 100.

Updated 3 September 2026 · By Sadeq

When to use it

Audit a family of live pages — every page one template produces, such as a set of service pages, tool pages or product pages — for search visibility and for whether an AI answer engine can extract and attribute a passage (generative engine optimization, nothing to do with geography). Use when someone asks to make a set of pages "more SEO friendly", "more GEO friendly", "AI-search ready" or "citable", asks what a page family is missing, or asks for a review before commissioning that work. It grades deployed HTML against a written rubric plus the evidenced GEO tactics, and reports ranked findings. It does not edit, does not publish and does not emit a score. Do not use it for a single blog post, or for Lighthouse, accessibility and Core Web Vitals.

Complete file

SKILL.md

---
name: page-geo-audit
description: >
  Audit a family of live pages — every page one template produces, such as
  a set of service pages, tool pages or product pages — for search
  visibility and for whether an AI answer engine can extract and attribute
  a passage (generative engine optimization, nothing to do with
  geography). Use when someone asks to make a set of pages "more SEO
  friendly", "more GEO friendly", "AI-search ready" or "citable", asks what
  a page family is missing, or asks for a review before commissioning that
  work. It grades deployed HTML against a written rubric plus the evidenced
  GEO tactics, and reports ranked findings. It does not edit, does not
  publish and does not emit a score. Do not use it for a single blog post,
  or for Lighthouse, accessibility and Core Web Vitals.
license: MIT
metadata:
  author: daena-digital
  version: "1.0"
---

# Page family SEO/GEO audit

Five passes over a set of live pages: **ground truth**, **the rubric**,
**the entity graph**, **citability**, **the template seams**. Report
findings, ranked, with the file that would fix each one. Change nothing.

The unit is a **family** — every page a template produces — not one page.
Nearly every finding turns out to be a property of the layout rather than
of a page, and reporting it once per page is six tickets for one edit.

## What this is not

- **Not an edit.** A question ends with an answer, not a commit. Say what
  the fix would be; make it only when asked.
- **Not a score.** No number out of 100. Borrowing a rubric's weights to
  produce a grade reads as a measurement it is not.
- **Not a single-post review.** One draft is a different job.
- **Not a quality audit.** Lighthouse, accessibility and Core Web Vitals
  are separate concerns with separate tools.
- **Not a promise.** Whether a product cites a page is not observable from
  the page. "More quotable" is the strongest claim available.

---

## Pass 0 — ground truth from the live HTML

**Read the deployed bytes, not the source and not a converted copy.**

Start from the sitemap, filter to the family's path prefix, and fetch each
URL raw. For every page record: the title, the meta description and its
length, the canonical, the `lang`, the `robots` meta, the h1 text, the full
heading tree in document order, the word count of the first passage after
the h1, every `application/ld+json` block and the `@type` in each, image
alt coverage, and the outbound links.

**Why not just fetch the page and read it:** the markdown converters behind
most fetch tools strip `<script>` blocks, so `application/ld+json`
disappears and a page with correct structured data reads as having none.
That produces a confident false negative on the one signal that matters
most. Verify structured data against raw HTML, always.

Read the source too, but second. The live page is what is true; the source
is where the fix goes.

Two things a measurement cannot judge, so judge them yourself:

- **"Passage under h1" is a word count, not a comprehension check.** A
  number inside the 40–60 band recommended by the structure guides means
  "read it", never "it passes". A number outside the band is the only part
  arithmetic can actually tell you.
- **Footer and nav headings appear in the heading tree.** "Services",
  "Company", "Get in touch" are chrome. Do not report them as content.

## Pass 1 — grade against a written rubric

Pick a rubric that is published, or at least written down, and grade
against it rather than against taste. Four categories cover the ground:

| Category | The question |
|---|---|
| Discoverable | Can crawlers reach it? robots.txt, the named AI crawlers, sitemap presence, redirect chains |
| Understandable | Titles, meta descriptions, one h1, `lang`, alt coverage, content type |
| Structured | Valid JSON-LD, an identity graph, breadcrumbs, canonical tags, markup that matches visible text |
| Citeable | Named authorship, a visible date, self-contained passages, source links |

Report each check the family would fail, its weight, and — this is the part
that lands — whether another family on the same site passes it. "The page
selling the service scores worse on our own rubric than the free tool
does" is one sentence and it is the whole argument.

Read the rubric's current text; do not recite it from memory. Weights move.

## Pass 2 — the entity graph

The question is whether a machine can tell that this page's provider and
the site's organization are the same business.

- **Is there an `@id` anywhere on the page?** A hand-built
  `provider: { '@type': …, name: … }` with no `@id` names the same company
  and is, to a consumer, a different entity.
- **Does the page reference the site's one organization node**, or does it
  mint a second description of the same company?
- **Does a visible breadcrumb have `BreadcrumbList` behind it?** A rendered
  crumb trail with no markup is the most common gap here.
- **Do the schema types match the visible content?** Google's rule, and the
  one that governs whether markup helps or hurts.
- **Does the machine-readable summary of the site describe these pages the
  way the pages describe themselves?** Hand-maintained files drift. Entity
  consistency is one of the few GEO levers genuinely in your control.

Map every one of these to the file that emits it before reporting.

## Pass 3 — citability

Can an answer engine lift a passage from this page and attribute it to you?

- **An answer-first block.** 40–60 words under the h1 that answer what the
  page is, who it is for and what the reader gets, without needing the
  heading above it.
- **Question-phrased H2/H3.** "How much does a custom web app cost?"
  extracts; "Pricing" does not. Count them — zero across a family is a
  finding.
- **Sections that stand alone.** Engines retrieve passages, not pages.
- **The h1 contains the thing being sold.** A slogan h1 with the service
  name only in the title tag leaves query matching to one field.
- **A named author or reviewer, and a visible date.** Usually missing on
  non-blog pages, and both are cheap.
- **Claims carry a source inline**, near the claim.

**The collision to name out loud.** The strongest evidenced tactic in the
one controlled study of this is "add statistics", and most honest content
policies forbid invented metrics, testimonials and client results —
especially for a young company with no results yet. Those reconcile in
exactly one direction: cite **third-party** figures with a source and a
date. Never your own outcomes. Raise this in the report rather than quietly
recommending "add proof points" and leaving someone to invent them.

## Pass 4 — the template seams

Findings nobody looks for, because they are absent rather than wrong.

- **Switched-off features.** A template capability disabled on every page
  that uses it is a decision nobody remembers making.
- **Orphaned assets.** Pages that used to link something and were
  rewritten without it. Free tools and calculators are usually the most
  citable assets a site has, and usually the least linked.
- **Hub pages with no schema at all.**
- **Meta descriptions over ~155 characters**, thin word counts on money
  pages, duplicate titles across the family.

---

## Things not to recommend

Each of these is either settled or actively wrong. Recommending one is not
a fresh idea.

- **FAQ schema as a ranking or AI-visibility lever.** Google retired FAQ
  rich results in full on 7 May 2026 and requires no special markup for
  generative search. Recommend the FAQ *section* for its visible answers.
  Suggest the markup only where genuine Q&A already exists.
- **`HowTo` schema**, same treatment — only for an actual procedure.
- **A machine-readable site summary file ahead of crawlable content**,
  accurate metadata and useful writing. Adoption is thin and it is a
  rounding error next to the page itself.
- **Keyword density, page length or schema volume.** None of the three
  appeared among the tactics that moved citation rates.
- **Any figure without a primary source.** "Sequential headings increase
  citation odds 2.8x" and "structured data earns 35% higher CTR" both
  circulate with nothing behind them.
- **A number out of 100.**

## Reporting

Open with three lines: status, what the reader must do, what happens next.

Then:

1. **What the research says**, briefly, with the caveats — including the
   parts that cut against the request. If someone asked for FAQ sections,
   the honest answer leads with FAQ markup being dead as an SEO feature.
2. **A table of the family's current state**, one row per signal. Facts,
   not adjectives.
3. **Findings, worst first**, each naming the file that would fix it and
   whether it is a template edit or a per-page one.
4. **A ranked build list**, cheapest-and-highest-value first, separating
   mechanical work from copy work — copy needs a person, and saying so is
   part of the answer.
5. **The calibration.** What is blocked by this (usually nothing), and what
   the real cost is.

Sources as links at the end when the report leans on research.

If a family is clean, say so in one line and stop. A review that
manufactures findings to look thorough is worse than a short one.

Sources

What this is based on

GEO: Generative Engine OptimizationAggarwal et al., KDD 2024 (Princeton University)
The Princeton GEO study: methodology, results and critiqueBlackalpaca
Changes to HowTo and FAQ rich resultsGoogle Search Central
Google drops FAQ rich results from searchSearch Engine Journal
How to structure content for AI searchExplainGEO
Content structuring themes for AI searchHubSpot