Start a conversationCrawling, rendering, indexing and page experience treated as engineering work: specified, ticketed, QA-ed on staging and measured after release. This is the ongoing technical discipline rather than the audit.
Overview
Technical SEO is the discipline of making a website reliably discoverable, renderable and interpretable by automated clients (Googlebot, Bingbot and the LLM crawlers that now feed generative answers). It covers crawl control and crawl budget, rendering strategy for JavaScript applications, indexing and canonicalization, internal link structure, site architecture, Core Web Vitals, and the Schema.org markup that states what a page is about. On-page work (titles, headings, semantic HTML, and internal anchors) sit inside the same discipline, because at scale it is produced by templates rather than written by hand.
It is continuous work rather than a deliverable. Crawl rules drift as facets are added, rendering behaviour changes with every framework upgrade, and a component refactor can silently drop canonical tags across a template. The practice is therefore closer to reliability engineering than to marketing: define the correct behaviour, instrument it, catch regressions before release, and decide what is worth fixing given finite engineering time.
Who it's for
Googlebot fetches a finite number of URLs per host per day, weighted by demand and server health. On faceted catalogues most of that allowance goes to sort, filter and session parameters. Server logs are the only direct record of where it actually goes; Search Console crawl stats corroborate but do not replace them, and robots.txt is a blunt instrument by comparison.
React, Vue and Angular assemble content in the browser. Search engines render in a deferred second pass that is neither guaranteed nor timely, and most LLM crawlers do not execute JavaScript at all. Whether a route is server-rendered, statically generated or hydrated client-side decides how much of your application is machine-readable, and diffing raw against rendered HTML is how you find out.
Crawled is not indexed. Canonical tags, hreflang and x-default, pagination, noindex directives and internal links together nominate which of a set of near-duplicate URLs represents the group, and conflicting signals routinely elect the wrong one. Architecture is the same argument at larger scale: what links to what decides where authority accumulates and what Googlebot bothers to revisit.
Titles, headings, semantic HTML, descriptive internal anchors and Schema.org types (Product, Article, FAQPage, BreadcrumbList) are on-page work, but on a large site nobody writes them individually. They are generated by templates and data fields, so the useful change is to the pattern and the source data, not to a list of pages.
What's included
Robots rules, parameter handling, faceted-navigation logic, canonical strategy and segmented XML sitemaps, set from log evidence rather than from defaults.
SSR, static generation and hydration decisions per route, plus LCP, INP and CLS work triaged by which templates actually carry commercial traffic.
Title, heading, internal-link and Schema.org patterns defined once at template level, with the source data that populates them checked for quality.
Staging crawls, rendered-versus-raw diffing and pre-deploy checks, so a refactor does not quietly remove canonicals across a hundred thousand pages.
Not sure which of these you actually need?
Request a discovery callProcess
1
Access to logs, Search Console, staging and the tracker, plus a full baseline crawl.
2
Crawl, log and render analysis by template and page type, reduced to ranked causes.
3
Tickets with acceptance criteria, written with your engineers and sized against their estimates.
4
Staging QA, release monitoring and measurement against the baseline, sprint after sprint.
Related case study · Fire & Flower
FAQ
No, and I keep them separate on purpose. An audit is a scoped, one-off decision document. This is the continuing discipline after it: specifying fixes, QA on staging, and reviewing releases so the same defects do not come back. Most clients buy the audit first and this second.
Yes, and that is most of the job. Recommendations go into your tracker with acceptance criteria and test cases, sized against your team's estimates, and I join refinement or stand-ups while the work is in flight.
Yes, if the routes that matter are server-rendered or statically generated. Client-only rendering is survivable for Google and close to fatal for the LLM crawlers, which largely do not execute JavaScript. The decision is per route and per template, not per site.
Yes. On a template-driven site, titles, headings, internal anchors and schema are produced by code and data rather than by a writer working through a spreadsheet. Changing the pattern changes a hundred thousand pages at once, which is why it belongs with the technical work.
Related resources
Technical SEO · 4 min
Technical SEO · 6 min
Technical SEO · 6 min
Technical SEO · 6 min
Technical SEO · 6 min
Send me your domain and the template you are least sure about. I reply personally within 48 hours.
