Lighthouse for GEO: Performance and Quality Auditing

Accessibility category

Accessibility and AI extractability share most of their failure modes. Missing alt text, missing form labels, low-contrast text, and incorrect ARIA all degrade both human and machine reading. Aim for 95+ here — the audits are largely binary, so a 95 means a small, fixable list.

Performance category

Slow servers and oversized payloads hurt every crawler, AI or otherwise. The audits that move the needle for AI retrieval specifically:

• server-response-time — keep TTFB under 600 ms; AI retrieval bots have aggressive timeouts
• render-blocking-resources — AI extractors often run with limited or no JavaScript
• unminified-javascript and unused-javascript — reduce the surface area of JS the crawler may not execute
• uses-text-compression — brotli or gzip

LCP breaks down into TTFB, Resource Load Delay, Resource Load Time, and Render Delay. When LCP regresses, look at the phase breakdown in the Lighthouse report rather than the headline number.

Best Practices

HTTPS, no console errors, valid source maps, no deprecated APIs. Low effort, high baseline-trust impact.

Running a GEO Audit Manually

1. Open Chrome DevTools (Cmd-Opt-I on macOS, F12 on Windows/Linux) on the target page.
2. Switch to the Lighthouse tab.
3. Select Performance, Accessibility, Best Practices, and SEO.
4. Choose Mobile (most AI agent traffic and Google's primary index are mobile-equivalent).
5. Use Navigation mode for cold-load metrics.
6. Click Analyze page load.
7. Repeat on at least three URLs per template (homepage, hub, leaf article) and on slow-network throttling.

For a quick CLI run:

npx lighthouse https://example.com/article-slug 
  --only-categories=performance,accessibility,seo,best-practices 
  --form-factor=mobile 
  --output=html,json 
  --output-path=./lhr

Lighthouse in CI

Manual audits are useful for diagnosis; CI is what keeps GEO regressions from shipping. The widely used integration is treosh/lighthouse-ci-action for GitHub Actions, which wraps Lighthouse CI v0.15.x and Lighthouse v12.6.

A minimal workflow that asserts thresholds and fails the build on regressions:

name: lighthouse
on: [pull_request]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            https://staging.example.com/
            https://staging.example.com/geo/what-is-geo
          configPath: ./.lighthouserc.json
          uploadArtifacts: true

With assertions in .lighthouserc.json:

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["warn", { "minScore": 0.8 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "categories:seo": ["error", { "minScore": 0.95 }],
        "categories:best-practices": ["error", { "minScore": 0.9 }]
      }
    }
  }
}

Keep performance as a warn, not an error — lab performance is noisy across runs; use CrUX or RUM to gate ship decisions on real-user data.

Common False Positives

• Third-party analytics killing performance. Tag managers, A/B test SDKs, and chat widgets routinely cost 20-30 performance points. Decide consciously whether the business value is worth it and document the trade-off.
• Lighthouse running on a 2016-equivalent phone with throttled 4G. It is meant to be a stress test. A 70 mobile / 95 desktop split is normal for content-heavy pages.
• Score variance run-to-run. ±5 points between runs is expected. Use median-of-five for any decision.
• Single-page apps reporting low SEO scores due to client-side routing. This is real, not a false positive: AI crawlers usually do not execute JavaScript, so SSR or static rendering is required for GEO.

FAQ

Q: Do AI providers use Lighthouse scores to decide which sites to cite?

No provider has publicly confirmed that. What AI extractors do care about — clean HTML, fast TTFB, semantic structure, accurate metadata — is what Lighthouse audits surface, so a clean Lighthouse report correlates with extractability without being a direct ranking input.

Q: Should I optimize for the lab Lighthouse score or CrUX field data?

Use Lighthouse to catch regressions in CI and CrUX to validate real-user experience. Google's ranking-relevant signal is field data; lab data is the canary that tells you something changed before users feel it.

Q: Lighthouse SEO score is 100 but I'm not getting AI citations. Why?

Lighthouse SEO covers structural readiness, not topical authority. A 100 means crawlers can read your page; it does not mean AI systems pick you as the best source. Pair Lighthouse with topical depth, internal linking, and structured data work.

Q: What target scores should we set in CI?

Reasonable defaults: SEO ≥ 95, Accessibility ≥ 95, Best Practices ≥ 90, Performance warn at 80. Tune by content template, not site-wide — hub pages and article pages have different floors.

Q: Is INP the same as the old FID?

No. FID measured only the delay before the first input was processed. INP captures the full interaction-to-paint cost across the worst-of-all interactions on the page, which is a far better proxy for perceived responsiveness. INP replaced FID on 12 March 2024.