Why is our site slow, and does it actually matter?
You’ve now heard it from three different people. The site’s slow. The Lighthouse score is red. Something about Core Web Vitals. Your developer says it’s the theme, the host says it’s the images, and nobody will tell you plainly whether any of it is costing you a single customer.
Sometimes it is. Often speed turns out not to be the real problem at all — the real problem is that a good chunk of the site isn’t being crawled properly and nobody had reason to look.
This is the part of SEO that behaves like engineering. It’s measurable, it’s fixable, and when it’s wrong it puts a quiet ceiling over everything else you spend money on.
What I actually touch
Crawling and indexing
What’s reachable and what isn’t. Crawl budget going to parameters and duplicates. Pages excluded that shouldn’t be, and pages indexed that never should have been. This is where the unglamorous wins usually are.
Speed, measured honestly
Field data where it exists, lab data where it doesn’t, and measured across the templates that matter — product pages, article pages, search results — not just the home page everybody optimises and nobody lands on.
Rendering
Whether your content exists in the HTML, or only after JavaScript has run. Google will usually cope with the second. Most AI crawlers won’t, and that’s a newer problem than a lot of sites have accounted for.
Structured data
Schema that validates, that matches what’s on the page, and that describes the right thing. Schema generator will show you the shape of it if you want to look before we talk.
The unglamorous list
Redirect chains, canonicals pointing at canonicals, a sitemap that disagrees with robots.txt, pagination, hreflang if you have it, and 404s quietly returning 200.
What you get
A prioritised list of fixes with the reasoning attached, written for whoever is going to implement them. If that’s your developer, it’s specific enough to hand straight over — the file, the rule, the expected result.
If it’s me, you get the work plus a before-and-after on the specific measurements we agreed to watch. Measurements, not rankings: no one can honestly attribute a ranking change to one technical fix, and I’m not going to pretend otherwise in an invoice.
Fair questions
Easier to scope once someone has looked
Technical health is one of the four areas in the Diagnostic, and any quote for fixes comes straight out of what it finds. That’s the sensible first step rather than buying hours blind.