DEV Community: Enlimited

The B2B Conversion Tracking Spec Developers Need Before Marketing Buys More Traffic

Mohsin Ali — Tue, 27 Oct 2026 07:41:10 +0000

A B2B site can count a newsletter signup and a demo request as the same conversion. Sales then works a small slice of those leads while marketing optimizes toward the rest.

B2B conversion tracking fixes that gap with one shared event taxonomy, written by developers and marketers together and tied to CRM lifecycle outcomes.

This post is the spec. It defines five conversion tiers, documents each event as a contract, shows a working taxonomy with a sample payload, covers identity and attribution, and ends with the QA pass to run before the next media buy.

Which events should a B2B site send to analytics, ad platforms, and CRM?

Send five tiers of events.

Micro-conversions, such as pricing-page views, usually belong in analytics. Lead captures can go to analytics, ad platforms, and the CRM when consent and platform policies allow. Qualified conversations, sales-qualified opportunities, and closed revenue should come back from the CRM as offline conversions, so ad platforms can learn from pipeline outcomes instead of form fills alone.

Step 1: Define five conversion tiers

Tier the events before anyone writes code. A demo request is an intent signal. An accepted opportunity is a business outcome. They need different weights in every platform.

Tier 1: Micro-conversions. Pricing-page views, integration-page views, video plays, and form starts. These show interest without a confirmed identity.
Tier 2: Lead captures. Demo requests, contact forms, content downloads, and chat conversations that produce an email address.
Tier 3: Qualified conversations. A meeting booked and held, or a lead accepted by sales after a qualification call.
Tier 4: Sales-qualified opportunities. A deal record created in the CRM with a stage, amount, and owner.
Tier 5: Closed revenue. An opportunity marked won, with a final value.

Tiers 1 and 2 begin on the website. Tiers 3 through 5 usually begin in the CRM. The tracking spec connects those two halves through consistent identifiers and lifecycle rules.

Step 2: Write the event contract

Document every event in the same eight fields in a shared sheet or repository. The contract resolves implementation questions before launch.

Event name: Lowercase snake_case, with one clear action and object, such as demo_form_submitted.
Business definition: One sentence a sales leader would approve.
Trigger: The exact user action or system change that sends the event.
Required properties: Fields that must be present for the event to pass QA.
Consent condition: The consent state required before the event can go to each destination.
Platform destinations: GA4, Google Ads, LinkedIn, Meta, CRM, or warehouse.
CRM owner: The person who confirms the matching lifecycle stage in HubSpot or Salesforce.
QA owner: The person who signs off on the live test before deployment.

Step 3: Build a practical B2B conversion tracking taxonomy

This taxonomy fits many B2B sites with a demo or consultation funnel. Change the names to match your funnel. Keep the underlying pattern.

Event	Trigger	Destinations
`demo_form_started`	Visitor focuses on the first field in the demo form	GA4
`demo_form_submitted`	Server confirms the form submission	GA4, Google Ads, LinkedIn, CRM
`meeting_booked`	Calendar tool returns a confirmed slot	GA4, Google Ads, CRM
`lead_qualified`	CRM lifecycle stage changes to sales-qualified lead	GA4, Google Ads, LinkedIn offline conversion
`opportunity_created`	CRM creates a deal with an amount and stage	Google Ads offline conversion, LinkedIn offline conversion, warehouse
`opportunity_won`	CRM deal stage changes to closed won	Google Ads offline conversion, warehouse

For website events, common required properties include form_id, page_type, utm_source, utm_campaign, gclid, lead_id, and consent_state.

Google’s data layer guide explains the implementation pattern: create window.dataLayer once, high in the page, and use consistent variable names across templates.

Here is an illustrative payload a developer can adapt to the event contract:

window.dataLayer = window.dataLayer || [];

window.dataLayer.push({
  event: "demo_form_submitted",
  form_id: "demo-request-v3",
  page_type: "pricing",
  utm_source: "google",
  utm_campaign: "brand-demo-2026",
  gclid: "Cj0KCQjw...illustrative",
  lead_id: "lead_8f3a2c",
  consent_state: "analytics_granted|ads_granted"
});

Step 4: Handle identity and attribution

Attribution often breaks at the handoff from the website to the CRM. These four rules keep the chain intact.

Persist first-touch and latest-touch values. Store utm_source, utm_campaign, and landing-page data in a first-party storage method that fits your consent approach. Write the permitted values into hidden form fields at submission.
Pass click IDs into the CRM. Store Google click IDs and relevant LinkedIn or Meta click identifiers with the lead record. Google’s offline conversion imports can match stored click data to later CRM outcomes. Enhanced conversions for leads can use hashed first-party data when configured with the required consent and policy controls.
Deduplicate form and calendar events. A buyer who submits a form and books a meeting is one lead with two tier events. Use the same lead_id to connect them.
Choose one source of truth for every tier. For qualified conversations, opportunities, and revenue, the CRM lifecycle or deal-stage change should usually be the source of truth. The website event records earlier intent.

In one Enlimited program for RepairDesk, the work included HubSpot attribution before paid activity scaled. Over 12 months, the program reached 280% of its MQL goal and reduced cost per lead by 91%. Results vary based on offer, sales process, tracking quality, traffic mix, and market conditions.

Step 5: Run QA before launch

Run the full chain with live tools before increasing budget. One controlled test click can reveal problems that a spreadsheet review misses.

Browser debugging: Open the browser console, trigger each website event, and confirm the dataLayer push includes every required property.
Google Tag Manager Preview: Confirm each tag fires once per event. Confirm consent rules block the intended destinations when consent is denied.
GA4 DebugView: Confirm events arrive in real time with debug_mode enabled. Check that parameter names match the contract.
CRM record inspection: Open the test lead and confirm permitted gclid, UTM values, lead_id, and lifecycle-stage data arrived.
Controlled paid-click test: Run one click from an active campaign through the funnel. Confirm the expected conversion appears once, in the correct destination, without a duplicate browser-side or server-side event.

Duplicate tracking often appears when server-side and browser-side tags both send the same conversion to the same platform. Choose one path per destination and document the decision in the event contract.

B2B conversion tracking checklist

Use this checklist in a README, ticket, or project board.

B2B CONVERSION TRACKING SPEC

[ ] Define five conversion tiers
    Test: Map every tracked event to micro-conversion, lead capture,
    qualified conversation, opportunity, or closed revenue.
    Owner: Marketing and Sales
    Priority: P1

[ ] Create the event contract
    Test: Document event name, definition, trigger, properties,
    consent condition, destinations, CRM owner, and QA owner.
    Owner: Marketing and Development
    Priority: P1

[ ] Implement website events
    Test: Validate dataLayer events, required properties, consent rules,
    tag firing, and destination-specific mapping.
    Owner: Development
    Priority: P1

[ ] Connect CRM outcomes
    Test: Confirm lifecycle and deal-stage changes map to imported
    ad-platform conversions with the correct identifiers.
    Owner: RevOps
    Priority: P1

[ ] Run end-to-end QA
    Test: Complete one controlled journey from paid click through CRM
    outcome and confirm no duplicate conversions appear.
    Owner: Marketing and Development
    Priority: P1

Tracking that points spend at pipeline

Three rules make B2B conversion tracking useful:

Tier conversion events so a demo request and a won deal carry different values.
Write every event as a shared contract that marketing, development, sales, and RevOps can use.
Close the loop with CRM outcomes so ad platforms receive stronger signals than form fills alone.

If paid campaigns report hundreds of conversions each month while sales accepts only a handful, the tracking setup is likely optimizing toward the wrong action.

For the broader strategy that connects tracking, channel choices, offers, and pipeline, read this B2B demand generation guide.

Frequently asked questions

What is B2B conversion tracking?

B2B conversion tracking connects website activity, CRM lifecycle stages, and ad-platform reporting. It helps teams distinguish early engagement from qualified leads, opportunities, and closed revenue instead of counting every form fill as equal.

Which conversion events should a B2B site send to Google Ads?

Track lead captures when they represent meaningful intent and your consent setup permits it. Then import later CRM outcomes, such as qualified leads, created opportunities, and closed revenue, when you can match them through click identifiers or an approved enhanced-conversions setup. Keep low-intent actions, such as pricing-page views, in analytics unless they serve a clear optimization purpose.

What goes into a conversion event contract?

Each event should include an event name, business definition, trigger, required properties, consent condition, platform destinations, CRM owner, and QA owner. Store the contract where marketing and technical teams can review it before deployment.

How do we stop duplicate conversions from server-side tagging?

Choose one reporting path for each event and destination. Connect related website and calendar actions with a shared identifier, such as lead_id, then test one controlled journey in Tag Manager Preview, GA4 DebugView, the CRM, and the ad platform.

Which CRM lifecycle stage should be the source of truth?

Use CRM lifecycle or deal-stage changes as the source of truth for qualified conversations, opportunities, and closed revenue. Website events record early intent. CRM records confirm whether that intent became a meaningful business outcome.

Your Sitemap Is Clean. Why Are Your Important Pages Still Orphaned?

Mohsin Ali — Tue, 27 Oct 2026 07:37:52 +0000

A URL can appear in your XML sitemap and still have no meaningful internal links pointing to it. That is an orphan-page risk. An orphan page audit compares your sitemap, a link-discovery crawl, and Search Console data to identify URLs that visitors and crawlers struggle to reach through your site.

The core question is simple: can a visitor and crawler reach this page through useful internal links from pages already on the site? An XML sitemap helps discovery, but it does not replace a coherent internal linking structure. Google's own sitemaps guidance says the crawler finds most pages by following links from pages it already knows, and a sitemap carries no promise of crawling or indexing.

This five-step process gives marketing and development teams a shared way to find, prioritize, repair, and validate disconnected pages.

Why does Google know our URL exists but fail to index, rank, or prioritize it?

Google uses several signals to discover, crawl, and understand URLs. Internal links help crawlers find pages, establish site relationships, and give visitors a path through the site. A sitemap can support discovery, but it does not make an unlinked page strategically important.

On JavaScript and headless CMS sites, important links may appear only after client-side rendering. That increases risk because crawlers differ in their JavaScript capabilities, rendering resources, and timing.

Step 1: Build three URL inventories

Start with three exports, because each one answers a different question. The crawler shows what links reach. The sitemap shows what you claim. Google Search Console shows what Google kept.

Crawler URLs: Start from the homepage with XML sitemap crawling disabled so the crawl reflects discovered internal links. Run one crawl with JavaScript rendering enabled. For JavaScript-dependent sites, run a second crawl with rendering disabled for comparison.
XML sitemap URLs: Pull every sitemap in the index file, including any the CMS generates on its own.
Google Search Console data: Export the Pages report and inspect indexed and excluded URL groups. Use URL Inspection for high-value examples because the Pages report is aggregated and does not provide a complete exportable inventory of every URL.

Then normalize all three lists the same way. Force one protocol and one hostname. Decide on trailing slashes and apply the rule everywhere. Strip tracking parameters. Replace every redirecting URL with its final destination. Record both the crawled URL and its declared canonical.

Consolidate duplicates only after reviewing whether the canonical is valid, indexable, and consistent with the sitemap and internal links. Flag noindex URLs separately. Exclude intentional noindex pages from the priority orphan list, but investigate any noindex page that appears in sitemaps, primary navigation, or commercial internal-link paths.

Normalization prevents false positives. For example, a trailing-slash mismatch can make one page look like two different URLs in a spreadsheet.

Step 2: Identify potential orphan pages

Compare the crawl list against the sitemap list and sort every URL into one of four buckets. The bucket tells you what broke, and this sort is the core of the orphan page audit.

In sitemap, found by crawl: Healthy. Leave it.
In sitemap, missing from a homepage-led crawl: Investigate as a potential orphan. Confirm the crawl configuration, robots rules, authentication, rendering settings, pagination, and alternate entry paths before calling it a true orphan.
Crawlable but excluded from sitemap: A sitemap gap. The links work, and the sitemap generator skipped it.
Indexed but absent from the current internal-link crawl: Investigate. Google may have discovered it through external links, older site versions, prior sitemaps, JavaScript-rendered links, or URLs beyond the crawl scope.

The second and fourth buckets deserve priority review when they contain pages tied to high-value buyer decisions, such as pricing, integrations, solution pages, comparison pages, or case studies.

On a headless CMS, run the crawl a second time with JavaScript rendering off. A URL that appears only when JavaScript rendering is enabled may depend on client-side rendering for discovery. Review the rendered HTML, the initial HTML response, and the navigation implementation before deciding how to fix it.

Google documents that JavaScript rendering can be separate from initial crawling. Other crawlers have different rendering capabilities, so server-rendered links remain the lowest-risk option for priority pages.

Step 3: Score business impact

Prioritize confirmed orphan pages by business value and recovery potential. Score each page on buyer intent, conversion role, Search Console impressions, external links, organic landing-page sessions, content freshness, and whether the page supports a high-value offer.

A forgotten pricing page, an integration page, a case study, or a category page sits at the point where a buyer compares vendors. An old tag archive from 2019 sits nowhere.

Use a simple 1-to-5 score for every criterion, then fix the pages with the highest combined score first. Document the scoring rules so marketing, sales, and development make the same choices.

A common B2B failure is a case-study hub that features only recent work while older, high-value proof pages lose their internal links. Audit hubs for both recency and business relevance. The proof that closes deals sits where nobody can find it.

Step 4: Fix the internal links

Add useful contextual links from relevant hubs, service pages, editorial content, and navigation paths. Aim for a short, logical click path to priority pages, without forcing every important URL into an arbitrary depth target.

Hubs: Link each orphan from its parent hub, such as the case studies hub, the services hub, or the integrations index.
Related articles: Add contextual links from genuinely relevant pages with descriptive anchor text that tells readers what they will find after the click.
Breadcrumbs: Use visible HTML breadcrumbs where they improve navigation on hierarchical sections. If you add BreadcrumbList schema, ensure it matches the breadcrumb trail users can see.
Service pages: Link integration and pricing pages from the service pages buyers land on from paid search.
Headless builds: Make priority navigation paths reliably available in the initial HTML or through a rendering setup you have tested with Google Search Console and your crawler. Do not rely on client-side navigation alone for high-value pages.

In one Enlimited program for Quantal Security, ranking keywords increased 220% over six months. The work included stronger search foundations and clearer service-page structure. Results vary by competition, site history, technical constraints, and content quality.

Step 5: Validate the repair

A repair is ready for validation after the updated links are live, crawlable, and visible to users. Confirm the implementation with a fresh crawl and targeted URL checks. Run these five checks after each deployment, and keep the results next to the orphan page audit sheet from Step 1.

Re-crawl from the homepage with the sitemap off and confirm every priority page now appears in the link-only crawl.
Inspect priority repaired URLs in Google Search Console. Confirm indexability, the Google-selected canonical where available, and whether Google can access the page. Use your crawl data to verify the internal referring pages because Search Console does not always expose every referring internal URL.
Open the rendered DOM for the pages that carry the new links and confirm the anchor tags exist as real HTML links with href attributes.
Maintain XML sitemaps with preferred, canonical, indexable URLs that return 200 status codes. Exclude redirected, blocked, and intentionally noindex URLs.
Monitor indexing, impressions, clicks, and landing-page behavior after the repair. Review timing in context because Google's recrawl and processing schedules vary by site and URL.

For a broader technical review that includes robots directives, canonical checks, rendering, and AI-search measurement, use this B2B SEO audit checklist.

Orphan page audit formulas and a sample triage table

Put the three normalized inventories in one Google Sheet, one tab each, with URLs in column A. These formulas provide a first-pass classification after normalization. Review every high-value result manually before deciding it is an orphan or sitemap defect.

Tab: Sitemap

Column A = sitemap URLs after normalization

B2: =IF(COUNTIF(Crawl!A:A, A2)>0, "Found by crawl", "Missing from crawl")
C2: =IF(COUNTIF(GSC!A:A, A2)>0, "Indexed", "Missing from GSC")

Tab: Crawl

Column A = crawl URLs after normalization

B2: =IF(COUNTIF(Sitemap!A:A, A2)>0, "In sitemap", "Excluded from sitemap")

Tab: GSC sample

Column A = inspected or exported priority URLs and their index-status classification

B2: =IF(COUNTIF(Crawl!A:A, A2)>0, "Linked", "Disconnected from navigation")

The same logic in pseudo-SQL, for teams that keep crawl data in a warehouse:

SELECT s.url, 'true orphan' AS bucket
FROM sitemap_urls s
LEFT JOIN crawl_urls c ON c.canonical_url = s.canonical_url
WHERE c.canonical_url IS NULL

UNION ALL

SELECT g.url, 'indexed but disconnected'
FROM gsc_indexed_urls g
LEFT JOIN crawl_urls c ON c.canonical_url = g.canonical_url
WHERE c.canonical_url IS NULL

UNION ALL

SELECT c.url, 'excluded from sitemap'
FROM crawl_urls c
LEFT JOIN sitemap_urls s ON s.url = c.url
WHERE s.url IS NULL;

Use normalized preferred URLs in every join. Keep original URLs in separate fields for debugging redirects, canonical conflicts, and parameter variants.

A sample triage table, scored from Step 3, looks like this:

Page	Bucket	Score and fix
`/pricing/enterprise/`	Potential orphan	5. Confirm crawl configuration, then add a relevant link from the pricing hub and related service pages.
`/integrations/hubspot/`	Indexed but disconnected	4. Add to the integrations index and two related posts.
`/case-studies/2022-payments-client/`	True orphan	4. Link from the case studies hub and the payments service page.
`/tag/webinar-2019/`	Excluded from sitemap	1. Review for user value. Keep excluded if intentional, or redirect, improve, or noindex based on the content decision.

Make priority pages reachable and consistent

Two takeaways from this orphan page audit. Internal links, canonical tags, and XML sitemaps should consistently support the preferred version of a page. Conflicting signals make it harder for search engines to understand which URL you want indexed.

A page that depends entirely on client-side links carries discovery risk. Test its rendered output and make priority paths reliably accessible to users and crawlers.

Google's guidance on AI features and your website makes the same point for AI answers: link your content internally and keep the important text in HTML. If a high-value page depends heavily on paid traffic, has weak organic visibility, or is missing from your internal-link crawl, investigate it before publishing more content or increasing ad spend.

Start with the pages closest to revenue: service pages, integration pages, comparison pages, pricing paths, and case studies. Confirm each disconnection, repair the relevant path, then recrawl before moving to the next group.

Frequently asked questions

What is an orphan page audit?

An orphan page audit compares a homepage-led internal-link crawl with sitemap data and priority URL status from Search Console. It identifies pages that may lack meaningful internal-link paths, then confirms the cause before recommending a repair.

Why are orphan pages a problem for B2B websites?

Orphan pages can be harder for visitors and crawlers to discover through the site. They also lose the context and pathways that relevant internal links provide. On B2B sites, the orphans are often pricing, integration, and case study pages, which are the pages buyers read right before they compare vendors.

Does a sitemap entry mean Google will index the page?

A sitemap helps Google discover URLs, but it does not guarantee crawling or indexing. Internal links remain important because they help search engines and visitors find pages within your site structure.

How do we find orphan pages on a JavaScript or headless CMS site?

Crawl the site twice from the homepage, once with JavaScript rendering on and once with it off, then compare the lists. A page found only when JavaScript rendering is enabled may depend on client-side navigation. Inspect how the links are delivered, test the rendered output, and make high-priority paths reliably available to users and crawlers.

How many clicks from the homepage should a priority page sit?

Keep priority pages easy to reach through logical hubs, navigation, breadcrumbs, and relevant contextual links. Review click depth as a diagnostic signal, rather than treating a fixed number of clicks as a ranking rule.

How to Audit Whether Your Website Is Ready for AI Search Citations

Mohsin Ali — Tue, 27 Oct 2026 07:28:10 +0000

A B2B page can rank in Google and still fail to appear when a buyer asks an AI assistant for an answer, comparison, or shortlist. An AI search citation audit checks the conditions your team can control: whether crawlers can access the page, whether its answer is easy to extract, whether its publisher is clear, and whether you can measure visibility over time.

For AI Overviews and AI Mode, Google states that a page must be indexed and eligible to appear with a normal Search snippet. Google requires no special AI markup or AI-specific file. Other assistants use different retrieval systems and policies, so treat crawlability and clear answers as practical foundations rather than a universal citation formula.

We use these five checks to find the technical and content gaps that keep important B2B pages hard to retrieve, verify, and measure. Below is a practical version your developer and content team can use today.

Why does our B2B site rank in Google but rarely appear in AI answers?

Rankings and citations reflect different systems and signals. A strong ranking shows Google found a page relevant for a query. A citation also depends on the AI product, the question, the available sources, and whether your page offers a clear, supportable answer.

A page that ranks on backlinks and broad relevance can still bury its answers in long paragraphs, block AI crawlers at the CDN, or send mixed signals about who wrote it.

Check 1: Confirm bots can crawl and render the page

A crawler needs reliable access to your core content before your page can be considered as a source. Test the full path from request to rendered text on your top 10 pages before anything else.

robots.txt: Document which crawlers your legal, security, and marketing teams choose to allow. Confirm Googlebot can crawl pages intended for Google Search and AI features. Review each AI crawler separately because access does not guarantee retrieval or citation. One leftover staging rule can block the whole site.
CDN and WAF rules: Bot protection often returns a 403 or a challenge page to AI crawlers. Pull your CDN logs, filter by user agent, and check the status each bot received.
Status codes and canonical tags: Each preferred, indexable URL should return 200 and declare the intended canonical. Use a self-referencing canonical for a standalone page. Use a different canonical only when another URL is genuinely the preferred duplicate. Redirect chains and conflicting canonicals split your signals.
Rendered HTML: Compare raw HTML with rendered output in Google’s URL Inspection tool. Google renders JavaScript in a queue, and its JavaScript SEO guidance notes that many other bots run no JavaScript at all. Put the core answer, key definitions, and conversion information in HTML that users and search engines can access reliably. Server-side rendering or pre-rendering reduces risk when content cannot depend on client-side JavaScript.

Owner: Developer or platform engineer.

Scope the fix after you identify the failure point. A robots rule may take minutes. Rendering, CDN, or application changes may require a release cycle.

Check 2: Make every answer easy to extract

Put a direct, self-contained answer immediately below each meaningful question heading. Start with one short paragraph, then add evidence, limits, examples, and implementation detail.

What an extractable page looks like

Concise definitions near the top of the page, before the backstory.
Comparison tables when they clarify a decision. Keep headers explicit, define terms, and avoid packing several ideas into one cell.
A named, linked source for every statistic.
Show an “Updated” date when the page has been materially reviewed or revised, and keep it consistent with the dateModified value in Article schema.

Review your highest-value pages and mark each heading pass or fail. Put the direct answer first, then support it with explanation, evidence, examples, or next steps.

Check 3: Validate entity signals across your site and profiles

Consistent publisher and author information helps users, search engines, and other systems understand who is responsible for a page. It also reduces confusion when your brand appears across multiple public profiles.

Compare your homepage, About page, author bios, LinkedIn, Google Business Profile, Crunchbase, G2, and Clutch side by side.

One organization name, spelled the same way everywhere.
One author name per article, with a bio, credentials, and a link to a profile page.
The same organization name, domain, logo, and core company description wherever the platform allows.
Accurate addresses, phone numbers, and contact details for the entity and market each profile represents.
Service descriptions that match across your site and third-party listings.

Check 4: Use structured data that tells the truth

Structured data gives search engines explicit information about content users can also see on the page. It can support eligibility for certain Search features, but it does not guarantee rankings, AI visibility, or citations.

Use Article schema for articles, Organization schema for company identity, Person schema for named authors, and BreadcrumbList for visible site hierarchy. Use FAQPage only when the page contains a genuine visible FAQ and the markup meets Google’s current eligibility rules.

Google's structured data guidelines require markup to be a true representation of the page content, and Google recommends JSON-LD because it is generally easier to implement and maintain.

Validate eligible markup in Google’s Rich Results Test. Fix errors before launch. Review warnings for relevance because some warnings identify optional properties rather than broken markup.

Do not treat llms.txt as a ranking or citation control. Google’s AI features guidance says no additional AI-specific files or special markup are required. Evaluate any llms.txt implementation with legal and technical owners before adding it.

Check 5: Measure your AI citations baseline

A citation baseline turns AI visibility into a number you can move, and it is the part of the AI search citation audit most teams skip.

Start with 20 to 30 buyer questions from sales calls, support tickets, CRM notes, Search Console queries, and competitor comparisons. Record the exact prompt, country, language, account state, date, and device context because AI results can vary by user, location, product settings, and time.

Log each run: date, engine, model or mode where visible, prompt, country, language, account state, answer type, cited domains, cited URLs, your citation status, your cited URL, buyer stage, screenshot or export link, and notes on answer changes.

After several monthly runs, you can identify recurring cited domains, question groups where you appear, and gaps that merit a page refresh, new evidence, stronger internal links, or a new asset.

For a broader B2B framework beyond this technical audit, read our Answer Engine Optimization guide.

AI search citation audit checklist

Use this checklist in a README, ticket, or project board. Assign one owner and one verification method to every item.

P1 issues block discovery, retrieval, or measurement.
P2 issues improve clarity, consistency, or implementation quality.

AI SEARCH CITATION AUDIT

[ ] Check 1: Crawl and render
    Test: Confirm Googlebot access, inspect 200/3xx/4xx responses,
    validate intended canonical, compare raw and rendered HTML.
    Result:
    Owner: Development
    Priority: P1
    Fix date:

[ ] Check 2: Extractable answers
    Test: Direct answer under each heading, definitions, tables,
    named sources, and visible last-updated date.
    Result:
    Owner: Content
    Priority: P1
    Fix date:

[ ] Check 3: Entity signals
    Test: Same organization name, author, logo, and contact details
    across site and public profiles.
    Result:
    Owner: Marketing
    Priority: P2
    Fix date:

[ ] Check 4: Accurate structured data
    Test: Validate eligible markup, confirm every marked property is
    visible and accurate, then review errors before warnings.
    Result:
    Owner: Development
    Priority: P2
    Fix date:

[ ] Check 5: Citation baseline
    Test: Run a controlled question set monthly and record prompt,
    location, account state, citations, cited URLs, and screenshots.
    Result:
    Owner: Marketing
    Priority: P1
    Fix date:

Build the conditions for AI visibility

Start with five controls: access, answer structure, publisher clarity, accurate markup, and consistent measurement. These steps strengthen the conditions for AI visibility. They do not control whether a particular AI system cites a specific page for a specific prompt.

If your team sees strong organic rankings but limited visibility in AI-assisted research, run this audit on the pages tied to your highest-value buyer questions first.

Run the audit first on the pages tied to your highest-value buyer questions. Record the baseline, fix the biggest access or clarity gap, then repeat the same test set before making the next change.

Frequently asked questions

What is an AI search citation audit?

An AI search citation audit reviews the technical and editorial conditions that can make important pages easier to retrieve, understand, and measure in AI-assisted search. It covers crawl access, rendering, answer structure, publisher clarity, structured data, and citation tracking.

How do we earn AI citations for a B2B website?

Improve your chances of appearing as a source by making key pages crawlable, publishing direct answers supported by evidence, keeping author and organization details consistent, and monitoring a controlled set of buyer questions. No tactic guarantees a citation.

Does schema markup guarantee a spot in AI Overviews?

No single tactic guarantees a spot in AI Overviews. Google requires only that a page be indexed and eligible for a snippet. Structured data should accurately represent visible content. Use the markup that fits the page type and meet the current requirements for any Google Search feature you hope to qualify for.

Should we add an llms.txt file to our site?

Google does not require llms.txt or special AI markup for a page to appear in its AI features. Prioritize crawl access, useful content, clear answers, and accurate technical implementation. Evaluate llms.txt separately before adding it.

How often should we rerun the citation baseline?

Rerun your baseline monthly or quarterly, using the same controlled prompts and documenting location, language, account state, date, cited sources, and answer changes. Use monthly checks when AI visibility is an active priority.