Among developers, technical SEO optimization has a reputation as a collection of superstitions. Some of that reputation is earned. The underlying concerns, though, are ordinary engineering problems: reachability, response consistency, render reliability, and latency. Framed that way, most of it becomes tractable.
Reachability
A crawler is an HTTP client with a budget and no patience. Anything requiring interaction before content appears is invisible to it. Anything behind a parameter combination it cannot guess will never be requested. The practical test is simple: fetch your important URLs with a plain client, no JavaScript execution, and check whether the meaningful content is present in the response body.
Response consistency
The same URL should return the same content to every client. Variation by user agent is a legitimate technical pattern in some contexts and a serious problem in this one. Geolocation redirects, A/B testing frameworks, and personalisation layers all introduce inconsistency that is difficult to debug after the fact. Log what was served, not just what was requested.
Render reliability
Client-side rendering is not fatal, but it is a dependency chain with more failure modes than server rendering. Each additional request between page load and content availability is another opportunity for a timeout. For templates that matter commercially, server-side rendering or static generation removes the entire class of problem. For everything else, client-side rendering is usually fine.
Latency
The metrics have specific definitions worth reading properly rather than optimising against a score. Largest Contentful Paint is dominated by the largest above-the-fold element, usually an image. Cumulative Layout Shift comes from elements that change size after load. Interaction latency comes from long tasks on the main thread, which almost always trace to third-party scripts.
Making it part of the pipeline
Crawl in CI and fail the build on new 404s or canonical inconsistencies. Track render output for key templates and alert on unexpected changes. Budget performance metrics the way you budget bundle size.
Treating it as a testable engineering property rather than a periodic audit is what stops the same issues reappearing after every release cycle.
Top comments (0)