Make your useful pages accessible and understandable.
Technical SEO is the work that helps search engines find, access and understand your website’s content. It includes crawlability, indexing controls, page responses, links and the signals that identify each page. Performance and mobile usability also affect the experience people have when they arrive. These foundations support good content; they cannot make an irrelevant offer useful.
For a business owner, a helpful starting question is: can a customer find the right page, understand it and take the next step? A slow product page, an unavailable service page or a contact link that goes nowhere can interrupt that journey before the quality of your work gets a chance to speak.
This guide gives you a first inspection you can run yourself. You do not need to buy a tool or book a call to see a Lighthouse report. Use the findings to ask better questions and choose focused improvements.
Check access before chasing a score.
Google’s minimum technical requirements are straightforward: Googlebot must be able to access the page, the page must return a successful HTTP 200 response, and it must contain indexable content. Meeting those requirements makes a page eligible for indexing; it does not guarantee inclusion or a ranking.
Check that important public pages open without a login and are reachable from ordinary links. A robots.txt rule controls crawling. A noindex instruction asks search engines not to index a page, and the crawler must be allowed to access it to see that instruction. Do not remove deliberate privacy or staging restrictions just to improve a report.
If you have verified your public site in Google Search Console, use URL Inspection for an important service or product page. Review its indexing status and run the live test to investigate current access. A successful live test is useful evidence of access, not a promise that the page will appear in search.
Further reading: Google Search Central — Technical requirements ↗Google Search Console — URL Inspection ↗
Give each page a clear job and a consistent address.
Use descriptive titles, meaningful headings and internal links that explain where they lead. Keep the page’s main explanation available as text. A visitor should be able to distinguish a service, an article and a contact page without interpreting vague navigation labels.
Where several URLs show the same or very similar content, use consistent links and an appropriate canonical URL to indicate your preferred version. A canonical is a signal to Google, rather than an instruction that guarantees which URL it will select. Avoid pointing a useful, distinct service page at an unrelated homepage.
Structured data can help search engines interpret a page and can make it eligible for supported rich results. Describe the content people can actually see: an article, a product or a business. Correct markup does not guarantee a rich result, and adding more markup cannot replace missing information.
Further reading: Google Search Central — Canonical URLs ↗Google Search Central — Structured data ↗
The quick route: run Lighthouse with PageSpeed Insights.
PageSpeed Insights is a free Google tool that runs Lighthouse for a web page and displays the report in your browser. It is a convenient first check for a public website, including when you are reading this guide on a phone. It tests the URL you enter, rather than auditing your entire site.
Open PageSpeed Insights and test your site ↗
- Open PageSpeed Insights using the link above. Paste the full public URL of a page on your site, including https://.
- Choose Analyze and wait for the report to finish. Start with the homepage, then test an important service or product page separately.
- Select Mobile and Desktop in turn. Compare each with later tests using the same device setting.
- Scroll to the Lighthouse diagnostics and review Performance, Accessibility, Best Practices and SEO. Open a flagged audit to see the explanation and affected elements.
- Save the report link with the tested URL, date and device setting. Pick one issue to investigate before running the next test.
Further reading: Chrome for Developers — Introduction to Lighthouse ↗
The browser route: run Lighthouse in Chrome.
Use Google Chrome on a computer for this route. You can inspect a local preview or an authenticated page from your own browser, whereas PageSpeed Insights needs a page its servers can reach. For a public-page baseline, use a fresh Incognito window and close unnecessary tabs to reduce interference.
- Open the page you want to test. Right-click the page and choose Inspect to open Chrome DevTools.
- Select the Lighthouse panel. If it is hidden, look in the panel overflow menu (»), or use DevTools’ More tools menu.
- Choose Navigation mode and Mobile. Enable Performance, Accessibility, Best Practices and SEO for a broad first check.
- Start the audit using Analyze page load or Run audit; the label can vary between Chrome versions. The page reloads while the test runs.
- Review the finished report. Use the report menu to save it, then repeat with Desktop selected. Record the device and settings alongside each result.
Further reading: Chrome DevTools — Run Lighthouse audits ↗Chrome for Developers — Lighthouse performance scoring ↗
Read the findings behind the four scores.
The category scores are a starting point. Open the failed audits and connect each finding to something a customer needs to do. A report may identify an oversized image, a missing label or a page signal that needs checking. Confirm the problem on the actual page before choosing a fix.
A Lighthouse SEO score reflects the automated checks it performs on that page. Even 100 does not prove that Google has indexed it, that its content matches a customer’s search, or that it will rank. Likewise, an automated accessibility result cannot replace using a keyboard, checking the reading order and testing whether the form makes sense.
- Performance: investigate slow loading, blocked work and unexpected layout changes. Read the measured timings and diagnostics alongside the headline score.
- Accessibility: inspect labels, contrast and other detected barriers. Follow up with manual checks of navigation, forms and focus.
- Best Practices: review the browser and implementation issues flagged by the report. A pass is not a complete security audit.
- SEO: inspect the page-level checks that help discovery and interpretation. Review indexing separately in Search Console.
Further reading: Chrome for Developers — What the meta description audit checks ↗Chrome for Developers — Lighthouse accessibility scoring ↗
Separate a lab test from real customer experience.
Lighthouse runs a controlled lab test. Its results depend on the test conditions, and your local computer, network and extensions can affect them. Do not treat a small score difference between different tools or machines as proof that a site has improved or deteriorated.
PageSpeed Insights may also show real-user data from the Chrome User Experience Report, covering the previous 28 days. Check whether that data describes the exact page or the wider origin. A new or low-traffic page may have insufficient data; that is not a failure or a zero score.
Core Web Vitals describe loading, responsiveness and visual stability through LCP, INP and CLS. A standard Lighthouse navigation run does not measure real-user INP; its Total Blocking Time diagnostic can help investigate responsiveness, but is not the same measurement. Use field data, when available, to understand what visitors experience over time.
Further reading: Google — About PageSpeed Insights ↗Google Search Central — Core Web Vitals ↗web.dev — Lab and field data differences ↗Chrome for Developers — Lighthouse performance scoring ↗
Turn the report into one useful improvement.
Prioritise access failures and broken customer journeys first. Then choose improvements with a clear effect on an important page: making its main content available sooner, preventing a button from moving during loading, or adding the label a form field needs. A perfect score is less useful than a page that people can find and use.
Write a short record: the URL, the problem, who it affects, the proposed change and the evidence you will check afterwards. Retest with the same settings after the change. Also open the page on a real phone and complete the relevant journey without submitting a real order or booking just for testing.
Use Search Console over time to review indexing, relevant search impressions and clicks. Those are different signals from a Lighthouse score. Neither tool alone establishes that an improvement caused more enquiries or sales.
If you want help interpreting your report, send us the page URL and the finding you are unsure about. We can start the discussion by email. Any technical review or implementation work is scoped separately before you commit; a call is available if you prefer one.
Sources & further reading
Sources checked on 28 October 2026. Research findings apply to the systems and populations studied; examples in this article are illustrative unless stated otherwise.
- Google Search Central — Technical requirements ↗
- Google Search Console — URL Inspection ↗
- Google Search Central — Canonical URLs ↗
- Google Search Central — Structured data ↗
- Chrome for Developers — Introduction to Lighthouse ↗
- Chrome DevTools — Run Lighthouse audits ↗
- Chrome for Developers — Lighthouse performance scoring ↗
- Google — About PageSpeed Insights ↗
- Google Search Central — Core Web Vitals ↗
- Chrome for Developers — What the meta description audit checks ↗
- Chrome for Developers — Lighthouse accessibility scoring ↗
- web.dev — Lab and field data differences ↗
YOUR NEXT MOVE