What actually counts as a "citation blocker"?

Anything that stops an AI crawler from reading, trusting, or lifting a passage from your page. That covers a wide range, content that only renders after JavaScript, missing or broken structured data, no author byline or publish date, a slow server response, or a heading structure that hides where the actual answer is. Some are a five-minute schema fix. Others need a rendering change from engineering. A seven-dimension audit catches most of them in one pass; sorting them by real impact is the harder part.

How do I know which audit findings to fix first?

Weight and severity, not gut feel. Static content, structured data, and citation readiness carry the most weight in the overall score, so a critical finding in one of those three moves the needle more than ten minor findings in accessibility. Inside a single page, fix critical findings before warnings, and fix the pages your audit already flagged as high-traffic or high-intent before the long tail.

What's the difference between the site audit and the Citation Optimizer?

The audit is a broad diagnostic. It scores every page you crawl across seven dimensions and tells you what's generally wrong. The Citation Optimizer is narrow and specific. It scores one page against one real search query and shows exactly which pipeline stage that page fails for that query. Run the audit to find your blockers site-wide, then run the optimizer on your fixed priority pages to confirm they'd actually win a specific search, not just score better in general.

Do I need engineering help to fix most of these?

Some findings, yes. Server-rendering JavaScript content or fixing Time to First Byte usually needs a developer. Most others don't. Adding a meta description, writing an author byline, adding FAQ schema, or restructuring a page's headings are edits a marketer can make directly in most CMSs. Sort your findings by who needs to fix them, and get the no-code list moving while you file a ticket for the rest.

How to Find and Fix AI Citation Blockers

To find and fix AI citation blockers, run a full-site audit that scores every page across the dimensions AI actually cares about, then triage the findings by scoring weight instead of raw count. Fix the highest-weight issues on your highest-priority pages first, turn those pages into a tracked project, and score a few of them against a real search query to confirm the fix would actually win a citation. Re-audit the same pages afterward and compare the numbers directly; that's the only way to know the fix landed instead of just looking right in the CMS.

Most sites accumulate these blockers by accident. Nobody sets out to render pricing pages entirely in JavaScript or ship a blog post with no author byline. It happens one CMS default, one theme update, one migration at a time, and none of it shows up in a normal SEO checklist because none of it is really about ranking in Google. It's about whether an AI crawler can even parse the page in the first place.

This guide works with any AI visibility workflow; the callouts show how each step runs in Spyglasses.

Step	What you're doing	What tells you it's working
1. Run the audit	Scoring every page across seven dimensions	A completed audit with per-page findings
2. Triage findings	Sorting by weight and page importance	A short, ranked priority list, not a raw findings dump
3. Fix the blockers	Resolving the highest-weight issues first	Dimension scores rising on your priority pages
4. Track and sharpen	Turning fixed pages into a project, scoring against a real query	A project tracking the pages, a passing pipeline score
5. Re-audit	Confirming the fix in a fresh crawl	Site score up, same findings gone

Run a full-site audit

Start with a full crawl, not a spot check. A citation blocker on your homepage and the same blocker on a product page you never look at both cost you the same way: AI can't cite either one. An audit that scores every page (or a representative slice of every page type) is the only way to find blockers you didn't know to look for.

A useful audit scores each page across several independent dimensions rather than producing one vague number. At minimum you want: how much content renders without JavaScript (GPTBot, ClaudeBot, and Googlebot for Gemini all skip client-side rendering by default), whether the right structured data is present, whether the content is actually structured for an AI system to lift a passage from, how fast the page responds, whether it carries trust signals like an author and a date, whether it's written at a readable level, and whether it follows basic accessibility practices. A page can look fine to a person and still fail several of these silently.

Triage the findings by impact

A full-site audit can easily return hundreds of findings. Fixing them in the order they appear on the page is a bad plan; some findings barely move the needle and some are the whole reason a page never gets cited. Triage by two things: how much weight that dimension carries in the overall score, and how important the page itself is to your business.

Dimension	Typical weight	What a low score usually means	Fix effort
Static content	22%	JavaScript-only rendering; crawlers see a blank page	Needs engineering (SSR/SSG)
Citation readiness	20%	No extractable answer near the top of the page	Content rewrite
Structured data	18%	Missing or wrong JSON-LD schema for the page type	Fast, often no-code
Performance	14%	Server response above 2 seconds to a crawler request	Needs engineering
E-E-A-T signals	14%	No author byline, no publish or modified date	Fast, often no-code
Readability	10%	Sentences and sections too dense to summarize cleanly	Content rewrite
Accessibility	10%	Missing alt text, broken heading order	Fast, often no-code

Static content, citation readiness, and structured data carry the most weight, so a critical finding in any of those three is worth more of your attention than ten minor accessibility warnings. Cross-reference that against which pages actually matter: a critical finding on your top product page outranks the same finding on an old archived post, even though the audit lists them side by side.

Pull quote: A site audit tells you what's broken. A tracked project tells you whether fixing it actually got you cited. — “A site audit tells you what's broken. A tracked project tells you whether fixing it actually got you cited.” — Spyglasses

Fix the blockers on your priority pages

Work the list top to bottom: highest-weight dimension, highest-priority page, first. A server-rendering fix that resolves a critical static-content finding across your whole product catalog is worth more than a week of small accessibility tweaks spread across the long tail. Route findings to the right owner as you go; some are a content edit you can make directly in the CMS, and some need an engineering ticket, so don't let the ones you can't fix yourself block the ones you can.

Don't try to clear every finding on every page in one pass. A focused fix on the pages that actually drive citations and revenue beats a shallow pass across the entire site, and it gives you a clean before-and-after to point to when you re-audit.

Track the fix and sharpen priority pages against real queries

Once your priority pages are fixed, don't let the work disappear back into a spreadsheet. Turn the page group you just worked through into a tracked project so any AI citation on those pages going forward is attributed to this specific effort, not lost in your site-wide averages.

While you're there, take your highest-priority fixed pages one step further. A page can pass every audit dimension and still lose the actual search that matters to a competitor's page. Score your top pages against a real, tracked search query to see whether they'd survive AI's retrieval pipeline for that exact query, not just score well in general. This is the same query-first check used in how to win a target AI grounding search; running it here confirms the fix holds up against a real search, not just a general score.

Re-audit to confirm the fix landed

A fix isn't done when it ships; it's done when the next crawl agrees with you. CMS previews and staging environments don't always match what a crawler actually sees in production, and a deploy that looked clean can still leave the old static HTML cached at the edge. Re-run the audit against the same page group you started with and compare the numbers directly, not from memory.

Expect most of the movement in the dimensions you actually touched. A structured-data fix should show up as a structured-data score jump, not a vague overall bump. If a dimension you fixed didn't move, the fix probably didn't ship the way you think it did, and it's worth checking the live page before moving on.

Blockers are found in a crawl, not a checklist

The pattern holds regardless of which tool runs the crawl: audit broadly, triage by weight and page importance, fix the pages that matter first, track the fix so it doesn't get lost, and re-audit before you call it done. Skipping the triage step is the most common way this goes wrong; teams burn a sprint on accessibility warnings while a critical structured-data gap sits untouched on the page that actually drives pipeline.

If you're optimizing pages you already have rather than starting from a site-wide audit, optimizing existing content for AI citation covers that page-first version of the work. And if you haven't run a baseline audit yet, a free AI Readiness Audit shows you exactly where your site stands before you fix anything.