Join our community of websites already using SEOJuice to automate the boring SEO work.
See what our customers say and learn about sustainable SEO that drives long-term growth.
Explore the blog →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.
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.

Here is the full SEO audit list, grouped by what each check is actually looking at, with my honest read on whether to care:
| Audit | What it checks | Worth fixing? |
|---|---|---|
| has-viewport-meta | Mobile viewport meta tag present | Yes, always |
| document-title | Page has a non-empty <title> | Yes, always |
| meta-description | Meta description present | Yes, for CTR |
| http-status-code | Page returns 200, not 4xx/5xx | Yes, obviously |
| link-text | Anchor text is descriptive (not "click here") | Yes, easy win |
| crawlable-anchors | Links resolve to a URL Google can follow | Yes, especially on SPAs |
| is-crawlable | Page is not noindex'd or blocked in robots.txt | Yes, critical |
| robots-txt | robots.txt is valid and accessible | Yes, table stakes |
| image-alt | Images have alt attributes | Yes, dual SEO + a11y |
| hreflang | hreflang tags are valid (if present) | Only if multilingual |
| canonical | Canonical tag points somewhere valid | Yes, prevents dilution |
| font-size | Body text at least 12px on mobile | Skip unless flagged |
| tap-targets | Touch targets 48x48px and spaced | Skip unless flagged |
| structured-data | Manual audit, not scored | Validate 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.
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:
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.
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.

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.
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).
Ranked by impact from my own audits on seojuice.com and the ~400 customer sites I have run through SEOJuice in 2025-2026:

X-Robots-Tag: noindex headers ship to production three times in two years — this is the single most consequential hygiene check.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.
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:

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:
numberOfRuns=3 with the assertion preset takes the median, which is the only way to make CI gating stable.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.
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.
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:
| Capability | Lighthouse | Ahrefs Site Audit | Screaming Frog | SEOJuice |
|---|---|---|---|---|
| Single-URL hygiene audit | Yes (best) | Yes | Yes | Yes |
| Core Web Vitals (lab) | Yes (native) | No | No | Yes (via Lighthouse API) |
| CrUX field data | No | No | No | Yes |
| Full-site crawl | No (one URL) | Yes | Yes (best) | Yes |
| Backlink profile | No | Yes (best) | No | Yes |
| Content quality / topic gaps | No | Partial | No | Yes |
| AI visibility tracking | No | No | No | Yes |
| CI integration | Yes (CLI) | API only | CLI | API + CI |
| Free tier | Free | Limited | 500 URLs free | Free 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.
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.
If you have a Lighthouse audit from last Tuesday and are not sure what to do next:
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:
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?
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?
Lighthouse > vanity. Prioritize crawlability & meta first. #SEO
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)?
Lighthouse score ≠ ranking?
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?
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?
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?
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?
no credit card required