A website can have a beautiful design, a green circle in its SEO plugin, and still lose people before the main content has even loaded. Or Google may index a different URL from the one you expect. Or an order may work, but measurement sends it twice.
That is why I do not start a technical audit by chasing a score of one hundred in a single test. First I look for errors that prevent business, indexing or use of the website. Only then do I polish the small details.
1. Verify that important URLs return the correct status
Review the main service pages, articles that receive traffic, contact page and conversion path. An important page should return 200. Permanently moved content should have one direct 301 redirect. A removed page should not quietly end up on the homepage.
I also check HTTP and HTTPS, www and non-www variants, trailing slashes and parameters. The result should be one canonical URL. Google describes a redirect as a strong canonicalisation signal and recommends combining it with a consistent canonical and sitemap in its documentation on canonical URLs.
2. Check indexing from the perspective of the real page
Robots.txt, meta robots, canonical and sitemap must work together. A common mistake is to index a page that has no place in search while blocking important content. Use URL Inspection in Search Console on several representative URLs. It shows what Google knows about the page and lets you test the live version.
- Is the canonical URL the one you want?
- Is the page available without sign-in or blocking?
- Does the sitemap contain only indexable 200 URLs?
- Do internal links avoid redirects?
- Are important pages orphaned?
Google maintains an overview of these areas in its documentation on crawling and indexing.
3. Measure speed on people, not only in the lab
PageSpeed Insights and Lighthouse are useful diagnostic tools. But a lab test is not the same as the experience of real visitors. The current Core Web Vitals are LCP, INP and CLS; field data works with real devices and connections. The official Web Vitals documentation explains the overview and the difference between field and lab data.
I would read priorities like this:
- LCP: when the main content appears.
- INP: how quickly the page responds to use.
- CLS: whether elements jump while loading.
- TTFB and network: whether anything starts happening quickly at all.
Google also explicitly says that a good score does not guarantee top rankings. Overall usability matters more than chasing a single number. See the page experience documentation.
4. Find the real culprit behind loading
In the waterfall and DevTools, look for long server time, blocking CSS and JavaScript, oversized images, fonts, repeated requests and third parties. The old rule to "combine all files" is no longer universal. With modern protocols, the amount of unused code and main-thread blocking can matter more.
- Load the main image at an appropriate size and in a modern format.
- Set image dimensions so they do not shift content.
- Content below the first viewport can use native lazy loading.
- Load only the required font weights and character sets.
- Load marketing scripts asynchronously and only where they serve a purpose.
- Compress text resources and set a long cache for versioned files.
A third party is costly not only in milliseconds. Every pixel, chat widget and heatmap creates further operational and data responsibility. If nobody uses the report, remove the script.
5. Go through the website as a customer with a keyboard and mobile phone
On mobile, go through the navigation, form, cookie dialogue and order. Enlarge the text, disable images, use a keyboard. Headings should form an understandable structure, a form needs labels, and an error message must say what to fix.
Every page should have a main task. That does not mean one button at any cost, but a clear hierarchy. Find further practical points in the basic UX checklist.
6. Fix resource and JavaScript errors
A 404 for an image, font or script is not cosmetic. It can break appearance, measurement or functionality. Check browser-console errors, failed network requests and repeated 5xx responses on the server. Test critical paths after every deployment.
7. Use structured data only for truthful content
Schema is not a way to force star ratings. It is a machine-readable description of what is actually on the page. Use a supported type and test it in the Rich Results Test. Google lists current supported formats and testing tools in its structured-data documentation.
8. Measurement must not break the website it is meant to measure
Load GA4, advertising platforms and other scripts in a non-blocking way. Name events after decisions, not every click. Verify duplicates, consent and whether anyone actually uses the data. Find a practical foundation in the articles about Google Tag Manager and Google Analytics 4.
9. Money and risk determine the order of fixes
- A broken order, form or sign-in.
- An unavailable or non-indexable important page.
- A security issue and outdated components.
- Major mobile usability and Core Web Vitals problems.
- Measurement errors that lead to bad decisions.
- Only then minor scores and cosmetic issues.
Technical SEO is the starting line. It does not win the race on its own, but a broken website can lose it before the starting gun. If you need to turn technical findings into business priorities, you can describe the website and the decision you are dealing with.