seojuice

Lighthouse SEO Audit Playbook for Founders

Vadim Kravcenko
Vadim Kravcenko
Oct 10, 2024 · 8 min read

TL;DR: Lighthouse is a hygiene scanner, not a ranking oracle. The SEO category checks 14 mostly cosmetic items; the Performance category is where Core Web Vitals (LCP, CLS, INP) actually intersect with rankings. Run it in three places (DevTools, CLI, PageSpeed Insights) because they disagree, fix the 8 audits that move the needle, automate the rest in CI, and stop chasing 100.

The question I get most from founders trying SEOJuice for the first time is some version of: "my Lighthouse SEO score is 92, why am I not ranking?" The honest answer is that 92 was already irrelevant once it cleared 80. The Lighthouse SEO category is a checklist of things that, if missing, will hold you back — it does not score the things that get you ahead. I learned this the slow way on seojuice.com between 2024 and 2026, after pushing one Performance score from 54 to 89 and watching some pages move six positions while others did nothing.

This playbook is the audit I wish I had given myself the first time I opened Lighthouse and felt overwhelmed by the 40-plus suggestions. It covers what the tool checks, what it deliberately misses, which audits earn their hour, how to wire it into CI, and where to look once you have squeezed everything from the Chrome panel.

What Lighthouse SEO Actually Checks

If you have run Lighthouse once you have seen the four big number wheels: Performance, Accessibility, Best Practices, and SEO. Each wheel is an aggregate of weighted audits. The SEO wheel runs roughly 14 audits in the current version, and every one is mechanical. Lighthouse checks for the presence and shape of HTML elements, not the substance of your content.

Three-tier grid of the 14 Lighthouse SEO audits grouped into high band (8 ranking-correlated checks), mid band (3 UX-correlated checks), and low band (3 mechanical hygiene checks)
All 14 Lighthouse SEO audits, grouped into three priority bands. The high band is the 8 that earn their hour. The low band is mechanical hygiene mostly already passing on modern sites.

Here is the full SEO audit list, grouped by what each check is actually looking at, with my honest read on whether to care:

AuditWhat it checksWorth fixing?
has-viewport-metaMobile viewport meta tag presentYes, always
document-titlePage has a non-empty <title>Yes, always
meta-descriptionMeta description presentYes, for CTR
http-status-codePage returns 200, not 4xx/5xxYes, obviously
link-textAnchor text is descriptive (not "click here")Yes, easy win
crawlable-anchorsLinks resolve to a URL Google can followYes, especially on SPAs
is-crawlablePage is not noindex'd or blocked in robots.txtYes, critical
robots-txtrobots.txt is valid and accessibleYes, table stakes
image-altImages have alt attributesYes, dual SEO + a11y
hreflanghreflang tags are valid (if present)Only if multilingual
canonicalCanonical tag points somewhere validYes, prevents dilution
font-sizeBody text at least 12px on mobileSkip unless flagged
tap-targetsTouch targets 48x48px and spacedSkip unless flagged
structured-dataManual audit, not scoredValidate separately

Everything above is mechanical pass/fail. The first eight are not optional; they are baseline crawl health. The next four are situational. The last two are usually fine unless you run a touchscreen-first design with tight tap targets.

What Lighthouse SEO does not do: it does not score content quality, topic coverage, search intent match, internal link graph, backlink profile, E-E-A-T signals, competitive landscape, or anything generative-AI-visibility related. Two pages with identical scores of 100 can rank 50 positions apart for the same query. The score is necessary, not sufficient.

What Lighthouse Deliberately Misses

The reason "92 SEO score, still not ranking" is so common is that the audits Lighthouse runs are about a tenth of what Google's ranking systems care about. Here is the gap, written as a list of things the tool will never flag:

  • Content quality and topic coverage. Lighthouse has no idea what your page is about. It cannot tell you that your "best CRM" article covers 3 of the 12 features your competitors cover. Hygiene audits cover the shape; topical audits cover the substance.
  • Backlinks and referring domains. Off-page signals are invisible to Lighthouse. You can score 100 across the board and still rank 80 because three competitors have 200 referring domains and you have 12.
  • Search intent match. Lighthouse cannot tell you that your "buy" page is targeting an "informational" query. The mismatch is a top reason pages with good hygiene still get buried.
  • Internal link structure. Lighthouse audits anchor text but not link distribution. A page with five descriptive anchors pointing to it ranks differently from one with zero — Lighthouse gives both the same SEO score.
  • AI visibility and citation patterns. ChatGPT, Perplexity, and Google AI Overviews cite pages using signals Lighthouse never measures (entity density, schema coverage, retrieval-friendly formatting).
  • Crawl budget and indexation rate. Lighthouse checks if one URL is crawlable; it does not flag that Googlebot is wasting 80% of its budget on stale paginated archives.
  • Real user metrics. The Performance score is a lab measurement on one machine, one network, one Chrome version. Your CrUX field data may look completely different.

Every minute spent grinding the SEO score from 92 to 100 is a minute not spent on the items above. The score has a ceiling on how much it can help; the items above do not.

How to Run Lighthouse Without Misleading Yourself

Lighthouse runs in three different places, and they routinely disagree by 10-20 points on Performance. Which one to trust depends on the question you are asking.

Three-card comparison of DevTools panel, Lighthouse CLI, and PageSpeed Insights with data source, what each is good for, what to watch out for, and when to use each
Three ways to run the same audit, three different answers. DevTools is for iteration, CLI is for CI regression checks, PageSpeed Insights is for what Google actually sees.

DevTools Lighthouse panel. Open DevTools, click the Lighthouse tab, pick categories, hit Analyze page load. Fast feedback loop, but the score reflects your local machine, CPU load, network, and any extensions you have running. Use it for iterative debugging while you fix things, not for reporting.

Lighthouse CLI. The command-line version is the same engine, but reproducible. Install with npm install -g lighthouse, then:

lighthouse https://yoursite.com/page \
  --only-categories=performance,seo,accessibility \
  --output=json,html \
  --output-path=./report \
  --chrome-flags="--headless"

Fresh headless Chrome, no extensions, predictable CPU throttling. The JSON output is what you parse in CI; the HTML output is what you share with a teammate.

PageSpeed Insights. The hosted version at pagespeed.web.dev runs Lighthouse on Google's infrastructure and combines the lab result with field data from CrUX (the Chrome User Experience Report). PSI is what you cite when stakeholders ask "what does Google see?", because the field data is closer to what enters the ranking signal than your laptop's lab score.

The pattern I use: DevTools while editing, CLI for CI gates, PSI for reporting. If you only run one, run PSI on the 10 URLs that drive 80% of your traffic and ignore everything else until those are clean.

Interpreting the Score (It Is Not a Ranking Factor)

This is the misconception that costs the most time. The Lighthouse SEO score is not a Google ranking input. The Performance score is also not a ranking input, but the underlying Core Web Vitals it surfaces are. The distinction changes what you optimize.

"Lighthouse is a great tool but it's not the goal. Use it to find broken things, not to chase a number." This framing, paraphrased from John Mueller's many comments on the topic, is the one I keep coming back to.

Google's Search team has been consistent here. Martin Splitt, who runs their web crawling outreach, has said repeatedly that Core Web Vitals are a tiebreaker, not a primary signal, and that a slow page with great content still beats a fast page with thin content. Google's March 2024 INP announcement confirmed INP replaced FID as the responsiveness metric, but the same post emphasized CWV is one factor among many.

In practice: if your Performance score is 30, your CWV are failing, and that is probably hurting you. If it is 75, your CWV are passing, and pushing to 95 will not change rankings noticeably. The curve is steep up to "passing" and almost flat after. The SEO score works differently: below 80 you likely have an actual bug (noindex tag, broken canonical, missing title), and "fixing" the polish audits above 80 often introduces new bugs (over-structured data, hreflang errors, canonical loops).

The 8 Lighthouse SEO Checks That Earn Their Hour

Ranked by impact from my own audits on seojuice.com and the ~400 customer sites I have run through SEOJuice in 2025-2026:

Four-tier priority pyramid of Lighthouse SEO checks: Tier 0 indexability gate (is-crawlable, http-status, canonical), Tier 1 SERP rendering (title, meta), Tier 2 crawl mechanics, Tier 3 mechanical hygiene
The eight that earn their hour, in priority order. Work the pyramid top-down — one indexability failure undoes 13 perfect scores below it.
  1. document-title and meta-description. The only two SEO audits where a fix translates directly into measurable CTR change. After rewriting 7 duplicate title tags on seojuice.com with intent-matched copy, CTR from search lifted about 15% on the affected pages within six weeks (measured in Search Console). Keep titles 50-60 characters, descriptions 140-160, both unique per page.
  2. is-crawlable. A misplaced noindex meta or robots.txt rule can quietly remove a page from the index. I have seen staging-environment X-Robots-Tag: noindex headers ship to production three times in two years — this is the single most consequential hygiene check.
  3. image-alt. On a recent customer audit, 340 of their 400 images had no alt text. Accessibility failure plus missed SEO opportunity (Google reads alt as content context, and image search is non-trivial referral traffic on visual sites). An alt-text generator is one of the few automatable wins in this list.
  4. canonical. Duplicate content is a top source of self-cannibalization. A canonical pointing to the wrong URL is worse than no canonical at all — it actively tells Google to consolidate signals on a page you did not mean.
  5. structured-data (manual). Lighthouse flags presence, not correctness. Use Google's Rich Results Test after Lighthouse passes. JSON-LD is the format Google prefers; microdata and RDFa are second-class.
  6. link-text. "Click here" and "read more" are dead anchors. Lighthouse will not flag every instance, but rewrite them on your top 20 pages. Pairs naturally with an internal-link audit.
  7. http-status-code. Lighthouse audits the URL you give it, not the full crawl. Pair it with a crawler that catches 4xx and 5xx across the site.
  8. has-viewport-meta. Trivial to fix, catastrophic if missing. Mobile-first indexing has been default since 2019; a missing viewport meta means your mobile rendering is broken and the mobile crawler sees nothing useful.

Everything else in the SEO category (font-size, tap-targets, hreflang, robots-txt): fix if flagged, ignore otherwise. The marginal points are not worth the engineering hours.

Automating Lighthouse in CI

The single thing that changed how I use Lighthouse: stop running it by hand. The CLI is reliable enough to wire into GitHub Actions and gate deploys on regressions. Here is the workflow I actually run:

Four-step GitHub Actions flow: PR opened, preview deploy URL captured, LHCI runs 5 trials and takes median, budget gate compares against thresholds (seo 90, perf 75, a11y 90)
The GitHub Actions wiring: PR → preview deploy → median of 5 LHCI runs → budget gate. The budget thresholds are what stop CI from crying wolf at every commit.
name: Lighthouse CI
on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install Lighthouse CI
        run: npm install -g @lhci/cli@0.13.x
      - name: Run Lighthouse against preview
        run: |
          lhci autorun \
            --collect.url=https://preview.example.com/ \
            --collect.url=https://preview.example.com/pricing/ \
            --collect.url=https://preview.example.com/blog/ \
            --collect.numberOfRuns=3 \
            --assert.preset=lighthouse:recommended \
            --assert.assertions.categories:performance=warn \
            --assert.assertions.categories:seo=error
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

A few things this workflow does that matter:

  • Three runs and the median. Single Lighthouse runs are noisy. numberOfRuns=3 with the assertion preset takes the median, which is the only way to make CI gating stable.
  • SEO is an error, Performance is a warning. SEO regressions are deterministic (you removed a meta tag); fail the build. Performance is partly noise; warn unless the regression is large.
  • Three URLs, not the whole site. Pick your homepage, your highest-revenue page, and your highest-traffic blog post. Running Lighthouse against 500 URLs in CI burns minutes and tells you nothing you couldn't get from a weekly batch.
  • Preview environments, not production. Run against PR preview deploys so you catch regressions before they merge. Production gates tell you you broke something after users already saw it.

If you ship multiple times a day, that's all you need. If you ship weekly, batch it into a cron job that runs Lighthouse against your top 20 pages overnight and posts the diff to Slack.

Where to Look Beyond Lighthouse

Lighthouse is the lab measurement. Production-grade SEO needs three more things on top.

CrUX field data. Real Chrome users, 28-day rolling window. This is what enters Google's ranking signals for Core Web Vitals. CrUX dashboards show LCP, CLS, and INP from actual visits — not from your laptop. The gap between lab and field can be 20+ points on slow networks. CWV impact tooling models how a fix would propagate to field data.

Site-wide crawl audits. Lighthouse audits one URL at a time. You need a crawler that walks the whole site, flags 4xx/5xx, finds orphans, identifies duplicate H1s, and shows your internal-link distribution. A full site audit catches structural problems Lighthouse will never see, because it has only ever seen one URL.

AI visibility tracking. ChatGPT, Perplexity, Claude, and Google AI Overviews now drive a measurable share of qualified discovery on most B2B sites. None of them care about your Lighthouse SEO score. They care about whether your page is structured, citable, and indexed in the retrieval corpus they query. This is the layer Lighthouse cannot see and will not learn to see.

Lighthouse vs the Other Audit Tools

Founders ask me this constantly: do I need Ahrefs Site Audit, Screaming Frog, Lighthouse, AND SEOJuice? They overlap less than the marketing suggests. Here is what each covers:

CapabilityLighthouseAhrefs Site AuditScreaming FrogSEOJuice
Single-URL hygiene auditYes (best)YesYesYes
Core Web Vitals (lab)Yes (native)NoNoYes (via Lighthouse API)
CrUX field dataNoNoNoYes
Full-site crawlNo (one URL)YesYes (best)Yes
Backlink profileNoYes (best)NoYes
Content quality / topic gapsNoPartialNoYes
AI visibility trackingNoNoNoYes
CI integrationYes (CLI)API onlyCLIAPI + CI
Free tierFreeLimited500 URLs freeFree trial

What I actually run: Lighthouse CI on every PR, Screaming Frog monthly for full-site crawls, SEOJuice continuously for AI visibility and CWV field data, Ahrefs for backlink intelligence. The tools are complementary, not substitutes — founders who try to do it all with one tool end up missing one of the four layers.

FAQ

Does the Lighthouse SEO score affect Google rankings?
No, not directly. Google has never confirmed it as a ranking signal. The audits it runs (meta tags, viewport, structured data presence) overlap with technical hygiene that Google evaluates separately. A perfect 100 does not make you rank. A score of 60, however, usually means something is broken that does affect rankings.

What is a good Lighthouse Performance score in 2026?
75 or above is solid; 90+ is excellent and rare on content-heavy sites. The score is a weighted aggregate of LCP, CLS, and INP (which replaced FID in March 2024). Don't chase 100; the work-to-reward ratio collapses after about 85, and the underlying CWV are already passing well before then.

Why does my Lighthouse score change every time I run it?
Lighthouse runs in your local browser, so your network, CPU load, and any extensions all influence the result. Run it three times and take the median, or use PageSpeed Insights for a server-side snapshot. For ranking-relevant numbers, look at CrUX field data rather than Lighthouse lab data.

How long after fixing Lighthouse issues do rankings improve?
Performance fixes that improve Core Web Vitals typically show up in field data after a few weeks (CrUX uses a 28-day rolling window). I have seen ranking shifts inside 6 weeks on pages already on page 2. Pages outside the top 50 usually need other improvements (links, content depth) before CWV gains help.

Is INP the same as FID?
No. FID only measured the latency of the first user interaction. INP measures the worst-performing interaction across the entire page lifecycle. web.dev's INP guide has the full definition. If your monitoring still reports FID, it is running on pre-March-2024 thresholds and needs updating.

Can I run Lighthouse on a staging site behind auth?
Yes, via the CLI with --extra-headers for basic auth or cookie injection. PageSpeed Insights cannot reach private URLs. CI-integrated Lighthouse against preview deploys is the cleanest pattern.

Should I block deploys on Lighthouse regressions?
Block on SEO regressions (deterministic). Warn on Performance regressions (partly noisy). Never block on Accessibility unless your team is committed to maintaining the score — failing builds on accessibility flags causes engineers to comment out the assertion, which is worse than no assertion at all.

What to Do This Week

If you have a Lighthouse audit from last Tuesday and are not sure what to do next:

  1. Run PageSpeed Insights on your top 5 traffic pages. Note the CrUX field data, not the lab score.
  2. Fix any SEO audit that is failing on those pages (usually missing title, missing meta description, or a stray noindex).
  3. If Performance is under 75, prioritize images first (WebP, lazy loading), then render-blocking JS. Those two together usually move 20-30 points.
  4. Wire Lighthouse CI into your PR pipeline so you stop running it by hand.
  5. Once the lab score is clean, switch attention to the things Lighthouse will never measure: content depth, backlinks, AI visibility, internal link distribution.

That last step is where most of the actual ranking work lives. A hosted Lighthouse runner handles the lab measurement; a hygiene audit covers the structural items Lighthouse only partially sees; the rest is content and link work no scanner can shortcut.

Want a single place that runs Lighthouse alongside the layers it misses? SEOJuice runs Lighthouse audits across your whole site automatically, pulls CrUX field data, tracks AI visibility, and surfaces the issues that actually move rankings. Free to try, no credit card.

Related reading:

Discussion (8 comments)

Sarah from Marketing

Sarah from Marketing

8 months, 4 weeks

Hey — framing Lighthouse as Google’s diagnostic check really clicked for me. I'm updating my mom's cafe site and starting with sitemap + mobile speed; roughly how long did you wait to see organic traffic improvements after fixing the Lighthouse SEO issues?

Maria Garcia, Performance Marketing Manager

Maria Garcia, Performance Marketing Manager

8 months, 3 weeks

Glad that framing helped — makes prioritization easier. In my work optimizing dozens of local SMB sites, I typically see Google re-crawl sitemaps within 24–72 hours, but measurable organic uplift often takes 4–12 weeks (local pack improvements can be faster). Actionable next steps: submit sitemap + request indexing in Search Console, address Core Web Vitals (image compression, caching, critical CSS), add LocalBusiness schema and optimize Google Business Profile. Happy to review the site — what CMS/host are you using?

SocialMediaPro

SocialMediaPro

8 months, 4 weeks

Lighthouse > vanity. Prioritize crawlability & meta first. #SEO

GrowthHacker23

GrowthHacker23

8 months, 3 weeks

tbh this guide nailed the 'why' — I focused on reducing CLS and deferring unused JS first, and rankings nudged up after ~6–8 weeks. ngl lab scores looked great but RUM showed slower real-user gains; would love to hear how you measure impact (Lighthouse lab vs field metrics)?

devops_guru

devops_guru

8 months, 2 weeks

Lighthouse score ≠ ranking?

MarketingNinja42

MarketingNinja42

8 months, 1 week

tbh I felt the “neck‑deep in running a business” part — same boat. Switched images to WebP, deferred non‑critical JS, and added Lighthouse CI to our pipeline; saw SEO score + Core Web Vitals improve after reindexing in ~6 weeks. Anyone else find Search Console lags way behind Lighthouse improvements?

MarketingNinja42

MarketingNinja42

8 months, 1 week

tbh the accessibility checks Lighthouse highlights (alt text, semantic headings) actually bumped our organic CTR and reduced bounce. Pro tip: run axe-core alongside Lighthouse to automate a11y fixes in CI. Anyone tried that combo?

SchemaSteve

SchemaSteve

8 months, 1 week

ngl Lighthouse's 'score out of 100' is a solid diagnostic, but imo don't treat lab scores as the whole picture — compare with CrUX/field data in Search Console. I added Lighthouse CI to our deploys last year and it caught regressions before they hit prod, saved us a lot of headaches. Anyone else running synthetic checks in CI?

John Smith SEO

John Smith SEO

8 months, 1 week

Hey — as someone running my family's bakery site, I totally feel the overwhelm. Lighthouse audits (performance, accessibility, SEO) made the problems obvious; we optimized images, enabled gzip and added local structured data and saw more search-driven foot traffic within weeks. How long do you usually recommend waiting to measure impact after those fixes?