Browser Debugging
Lighthouse Audit Checklist
Turn a Lighthouse report into practical fixes for performance, accessibility, SEO, best practices and static-site quality. This reference is written as a practical operating note for developers, DBAs and platform teams who need to make the next troubleshooting step visible.
Use it with the live Formalint tools, then keep the final finding in a ticket, release note or runbook so the next person can repeat the same checks.
Good fit for
- A page has impressions but weak click-through or poor experience metrics.
- A newly published guide needs a final quality pass.
- A developer wants quick checks before Search Console resubmission.
Practical workflow
| Step | What to verify |
|---|---|
| Run mobile and desktop | A page can pass one profile and still fail the other because layout and main-thread cost differ. |
| Fix blocking items first | Prioritize crawlability, title, meta description, contrast, broken links and severe performance bottlenecks. |
| Retest one URL | Measure the changed page before applying the same template fix everywhere. |
| Document the fix | Add the update to the changelog when it meaningfully changes the public site. |
Command or evidence sample
Chrome DevTools > Lighthouse > Navigation > Desktop and MobileQuality checklist
- Confirm the public URL, browser, terminal, deployment or Search Console context.
- Capture the first useful error, header, status, sitemap entry or metric before editing.
- Keep secrets, tokens, cookies and private user data out of copied examples.
- Make one meaningful fix, publish it, then verify the live page rather than the local preview.
- Link the page to related Formalint references so visitors and crawlers can understand the topic cluster.
Common mistake
The common mistake is chasing a perfect score while ignoring whether the page answers the searcher's intent.
Formalint's rule for this topic: improve the page because it helps a real developer, then let Search Console observe the improvement naturally.
Related Formalint references
Continue with Core Web Vitals Debugging, Google Search Console Indexing, Browser Console Debugging.
Frequently asked questions
Should this be checked after every release?
Check it whenever the related page, deployment path, crawler signal, browser behavior or user-facing workflow changes in a meaningful way.
Can I use sensitive production data in examples?
No. Redact secrets and personal data before copying commands, URLs, payloads, logs or screenshots into a public tool or support note.