Technical SEO Consulting

Where the line falls between an audit and this

An audit is a diagnostic artifact. It tells you what is wrong, how much each problem is likely costing, and in what order to address it. It ends when you receive it. This engagement starts where that ends: taking findings, turning each into an instruction precise enough for a developer to implement without a follow-up call, sitting with the release, and confirming in production that the fix does what it was supposed to do.

The two are sold together often enough that buyers assume they are one thing. They are not, and conflating them costs money in both directions. Paying for an implementation engagement when what you needed was a diagnosis wastes the difference. Buying an audit when the real constraint is that nobody in the building can act on a technical finding produces a document that ages on a shared drive.

A useful test: if you have a competent development team and no list of problems, buy the audit. If you have a list of problems and a team who will implement anything as long as someone tells them exactly what and can prove afterward that it worked, buy this.

Crawl, render, index — and the three places sites break

Google describes the pipeline in three phases: crawl, then render, then index. Each has its own failure mode, and treating them as one process is why so many technical problems get misdiagnosed.

Crawling is the fetch. A URL that returns a server error, that is blocked in robots.txt, or that is only reachable through a form or a script event does not reach the next phase at all. A page enters the render queue only after being crawled successfully with an HTTP 200 response.

Rendering is the execution of JavaScript in an evergreen version of Chromium. Google states plainly that a page may sit in the render queue for a few seconds but can take considerably longer, and publishes no bound on it. One detail is badly under-known and worth checking on any JavaScript-heavy site: the rendering service may ignore caching headers, which can leave it executing outdated JavaScript or CSS. Google's own mitigation is content fingerprinting in asset filenames. The diagnostic is the URL Inspection tool in Search Console, which shows the rendered HTML rather than the source.

Indexing is where duplication, canonical conflicts and quality thresholds bite. A page can be crawled and rendered perfectly and still be discarded. Google's own position on server-side rendering is worth quoting because it is broader than most people expect: pre-rendering makes your website faster for users and crawlers, and not all bots can run JavaScript. In 2026 that clause is about the whole crawler ecosystem, not only Googlebot.

The page experience numbers that actually count

Core Web Vitals is a set of three metrics, and every one of them is assessed at the 75th percentile of real page loads, segmented by mobile and desktop. That last part is the part people miss. A lab test on a fast laptop is not the measurement; the measurement is what the slowest quarter of your actual visitors experienced.

• Largest Contentful Paint (LCP) — how long until the biggest visible element has rendered. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP) — how long from a user interaction until the next frame is fully painted. Good is 200 milliseconds or less; above 500 milliseconds is poor.
• Cumulative Layout Shift (CLS) — how much the layout moves under the reader while they are trying to use it. Good is 0.1 or less; above 0.25 is poor.

Two clarifications that change what gets worked on. INP replaced First Input Delay as a stable Core Web Vital in 2024 — anyone still reporting on FID is reporting on a retired metric. And INP counts only three interaction types: mouse clicks, touchscreen taps and key presses. Scrolling, hovering and zooming are excluded, so optimizing scroll performance does not move it. CLS is not the sum of every shift either: shifts less than a second apart are grouped into a burst capped at five seconds, and the score is the largest single burst. Definitions and thresholds are published on web.dev.

Crawl budget, and the honest answer for most sites

Crawl budget — how much crawling a search engine is willing and able to do on your site — is the most oversold concept in technical SEO. Google's documentation is specific about when it matters: sites with more than a million unique pages whose content changes moderately often, roughly weekly; sites with more than ten thousand unique pages whose content changes very rapidly, daily; and any site with a large proportion of URLs sitting in Discovered — currently not indexed in Search Console.

Below those thresholds it is almost never the constraint. If your site has a few thousand URLs and someone has quoted you for a crawl budget optimization project, they are selling you something you do not need, and the correct response is to ask which of Google's three stated conditions your site meets.

Where it does apply, the levers are unglamorous. Return 404 or 410 for permanently removed pages, which Google describes as a strong signal not to crawl that URL again. Fix persistent 5xx and 429 responses, because both are rate-limiting signals that actively reduce crawl capacity. Support 304 Not Modified so unchanged pages need not be re-downloaded. Keep sitemaps accurate, including <lastmod>. And do not reach for noindex — Google is explicit that it is the wrong tool here, because the page is still requested and then dropped, spending the crawl anyway. A robots.txt disallow is the documented instrument.

Faceted navigation and the parameter sprawl it creates

Filter and sort controls generate URLs combinatorially, and crawlers cannot tell whether a novel URL is useful without fetching it first. Google's description of the mechanism is unusually candid: crawlers will typically access a very large number of faceted URLs before determining that they are useless. On a large catalog this is the single biggest source of wasted crawling.

The decision comes first: should these URLs be indexable at all? If not, Google's preferred controls are a robots.txt disallow on the parameter combinations, or moving the filter state into a URL fragment such as #color=blue, which is never crawled. Notably, Google states that rel="nofollow" and rel="canonical" are generally less effective in the long term for this purpose — which contradicts a great deal of received practice and is worth raising with whoever built the current setup.

If some facet URLs should be indexed — because people genuinely search for that combination — then the rules are mechanical: use & as the parameter separator rather than commas, semicolons or brackets; keep filter ordering in the URL consistent so the same selection always produces the same string; and return 404 for empty result sets and nonsensical combinations rather than a thin page that says nothing matched.

How a finding becomes a change in production

The steps are dull, and that is the point.

1. Reproduce. Confirm the problem exists as described, at the URL level, with the response captured. A finding that cannot be reproduced does not go on the list.
2. Specify. Write the rule, the affected URL patterns, the expected response, the edge cases, and the test that proves it. Written for whoever will actually build it, in their vocabulary.
3. Stage. Where the change is structural — redirect rules, canonical logic, rendering changes — crawl the staging environment before it ships rather than discovering the problem in production.
4. Ship and verify. Re-fetch the affected URLs after release. Check the rendered HTML, not the source. Confirm status codes as served rather than as intended.
5. Watch the instrumentation. Page Indexing and Crawl Stats reports for the response-code mix and host status, then query-level performance once the pages have been recrawled.

Steps four and five are the ones routinely skipped, and they are where a project either produces a result or produces a story about one.

What you receive, and how long it takes

The artifacts are the specifications themselves, a handover session with whoever is implementing, and a verification record: what was specified, what shipped, what the response was before and after, and what remained outstanding. That last document is the one to ask any provider for, because it is the only thing that distinguishes work done from work described.

Two to six weeks of work is typical, but the calendar is set by your release cycle rather than by mine. A team that ships weekly finishes faster than a team with a quarterly release train, regardless of how quickly the specifications are written. Site size, template count, platform restrictions and the number of parties who have to agree are the other drivers.

On when the change appears in search: technical fixes are among the faster-acting work, because the effect follows recrawling rather than reassessment. But Google publishes no bound on the render queue, and states that some changes take effect in a few days while others could take several months. Anyone offering a date is inventing it.

When you should not buy this

If nobody has diagnosed the site yet, start with an audit. Implementation without diagnosis means fixing whatever is most visible, which is rarely whatever is most costly.

If the site is small — a few hundred URLs, one template family, a mainstream platform in its default configuration — the technical surface is genuinely thin. There will be a handful of things worth fixing and they will not fill a project. A short review is the right size.

If organic traffic fell and you have not checked the Manual Actions report in Search Console, check that first. A manual action is a different problem with a different remedy, and no amount of technical work resolves one.

And if the honest diagnosis is that the pages are technically sound and simply are not the best answer to the query, this engagement cannot fix that. Google's phrasing is worth keeping in mind: if there is more deserving content, it will continue to rank. That is a content and positioning problem wearing a technical costume, and it is worth saying so rather than billing for a crawl.

Frequently Asked Questions

Published 2026-08-11