Lighthouse Audit: How to Run It and Decide What to Fix

A Lighthouse report can give one page four category scores, yet a change in a single score does not tell a team what to fix first. Chrome’s Lighthouse panel checks Performance, Accessibility, Best Practices, and SEO; the useful work starts when those results become a short, evidence-backed task list.

This guide shows how to run a Lighthouse audit, read its findings, repeat the test fairly, and choose the next fixes. It also explains why the SEO score is not a verdict on a site’s search strategy.

What a Lighthouse audit checks

Google Lighthouse is an automated, page-level audit. It loads a URL, runs checks, and produces a report with scores and individual findings. Its results describe the tested page under the conditions of that run—not every page or every visitor’s experience.

The four main categories answer different questions:

• Performance: How quickly does the tested page load and respond under the test conditions? Metrics and insights point toward possible bottlenecks.
• Accessibility: Can automated checks detect barriers such as missing accessible names or inadequate color contrast? Passing them does not replace testing with people or assistive technology.
• Best Practices: Does the page meet the browser and implementation checks included in this category?
• SEO: Can Lighthouse detect certain basic issues that may affect how search engines discover or understand this page?

A finding is a reason to inspect a page, not proof that the same problem affects an entire site. A complete technical or content SEO review needs evidence beyond these four categories.

How to run a Lighthouse audit

For a first report, use the Lighthouse panel in desktop Chrome DevTools. It gives a founder or marketer a direct view of the tested page and its findings. It can also audit a page that requires authentication.

1. Open the exact page to test in Chrome, then open DevTools by right-clicking and selecting Inspect.
2. Select the Lighthouse panel. If it is not visible, find it in DevTools’ additional panels menu.
3. Choose a device type and select Performance, Accessibility, Best Practices, and SEO for a baseline report.
4. Run the audit, then save the report or record its date, URL, device setting, and key findings.

Choose a representative URL rather than defaulting to the homepage. For a publishing site, an article may reveal image, font, or template issues that the homepage does not. A second article can help distinguish a shared-template problem from a page-specific one.

Other methods serve different needs. PageSpeed Insights offers a quick check of a public URL without opening DevTools. The Lighthouse Chrome extension can generate a report, while the Lighthouse Node CLI suits repeatable or automated checks but requires more setup. Chrome also documents Lighthouse CI for monitoring regressions; a lean team can start with DevTools before adding automation.

How to read a Lighthouse report—and what counts as a good score

Start with category scores to locate areas needing attention, then open individual findings. A score summarizes checks in that category; it is not a pass/fail judgment on the entire site. A green SEO score, for example, cannot show whether important articles are indexed or whether a topic has been covered well.

For each finding, record the affected element or URL, the evidence shown, and the suggested action. If a performance insight points to a large article hero image, inspect the actual asset and page template before assigning a fix. If an accessibility finding identifies an unlabeled button, check how that button works for a visitor rather than treating the score alone as the task.

A useful score is a starting point, not a finish line

Lighthouse category scores use a 0–100 scale, and each category has its own score. Scores in the 90s generally indicate a good result, but a team should not spend a week chasing 100 while a severe, repeatable issue affects visitors. A lower score deserves investigation, not an automatic rebuild.

Findings can also change by Lighthouse version. Chrome’s Lighthouse 13 release notes describe Performance insights replacing older, non-scored audits while stating that Performance scoring did not change in that release. When comparing reports from different versions, check underlying findings instead of matching labels blindly.

How to prioritize findings for a lean team

Turn the report into a fix list rather than forwarding a screenshot of its scores. A simple triage pass considers visitor impact, severity, reach, confidence, and effort:

1. Identify the visitor problem. Does it block a task, make a control difficult to use, or slow an important page?
2. Check reach. Does it affect one URL, every article using a template, or a site-wide component?
3. Verify the finding. Can someone reproduce it and identify a plausible cause?
4. Estimate effort and ownership. Is this a content edit, a shared-template change, or an engineering investigation?

A worked example: choose, fix, and rerun

Suppose an article report flags an unlabeled menu button and a large hero image. First, inspect the menu with a keyboard and screen reader, then check two other article URLs. If the button lacks an accessible name on all three, the team has a verified shared-template issue. Inspect the image asset separately: it might be oversized on only the tested article.

With one developer slot available, the repeated menu issue takes priority over a speculative image optimization because it affects navigation across the template. The developer adds an appropriate accessible name to the shared button, and an editor checks that the label describes its action. The team then reruns Lighthouse on the same URL and device setting, checks whether the button finding clears, and tests another article to confirm the template fix reached it. If the issue persists, the task stays open; a higher score alone would not close it.

That order is not universal. If the image is confirmed to slow a high-priority landing page and the button issue does not reproduce, a page-specific image fix may come first. Record the decision and its evidence so the next task does not depend on whichever score looks worst.

How to make audit results more reliable

A Lighthouse performance audit is a controlled, lab-style run. Scores can move when the testing device, network conditions, browser workload, page content, or third-party scripts change. One better score is therefore weak evidence that a fix worked.

Test the same URL and device setting more than once under comparable conditions. Keep a history of the date, settings, report, and change made. Look for a consistent pattern in the underlying metric or finding before declaring an improvement. If a site serves substantially different regions, regional tests may reveal differences; keep the test location consistent when comparing results over time.

Page choice matters just as much. Test an example of each important page type—such as an article, product page, and signup page—rather than treating one homepage report as a site audit. When a result seems surprising, inspect the page directly and ask a developer to check the relevant request, script, or component.

What Lighthouse can—and cannot—tell you about SEO

A Lighthouse SEO audit checks selected characteristics of the page it loads. It is useful for spotting basic page issues. It does not establish whether important URLs are indexed, which queries bring impressions, whether content answers search intent, or how rankings compare with competitors.

A fuller review needs separate evidence: inspect indexing in Google Search Console, check important page templates and internal links, review content coverage, and investigate site-wide technical issues. For a lean team, that separates a detectable page fix from the editorial decision about what deserves to be published next. Lighthouse can inform the first decision; its report cannot make the second.

FAQ

How do you get a Lighthouse report?

Open a page in desktop Chrome, launch DevTools, select the Lighthouse panel, choose a device and audit categories, and run the audit. The panel displays category scores and findings. PageSpeed Insights offers another way to check a public URL. Save the report and its settings if the team intends to compare it with a later run.

What is Google Lighthouse used for?

Google Lighthouse is used to find potential page-level issues in Performance, Accessibility, Best Practices, and SEO. Its report helps a team identify what to inspect and test next. It is not a complete assessment of a website, and automated accessibility or SEO checks cannot replace human review and broader site analysis.

Is Google Lighthouse free to use?

Yes. Lighthouse is open-source and available through Chrome DevTools; its basic audit workflow does not require a paid subscription. Teams may still incur costs for development time or separate services used to store, schedule, or analyze repeated tests. Those services are optional, not a requirement for getting a report.

Why can Lighthouse performance scores change between runs?

A run captures one page load under particular conditions. Differences in browser workload, network behavior, changing content, and third-party resources can alter the measured result. Run the same page several times with consistent settings, then compare findings and metrics as well as the score. Treat a repeatable improvement as more meaningful than one unusually high result.

For teams pairing technical checks with a review-first publishing workflow, Start free.