Technical SEO is everything affecting whether a search engine can find, read, understand and rank your pages, as distinct from the content on them and the links pointing at them.
It has an unhelpful reputation because of how it is sold. A tool crawls a site in seconds, produces a hundred-page PDF of issues ranked by the tool severity rather than by business impact, and that document is presented as consulting. Most of what it lists changes nothing.
The genuinely important parts are a short list, and a site that gets them right is technically fine regardless of what a crawler says about meta keyword tags or image dimension attributes on a footer logo.
Technical debt that only shows up later
Some technical decisions cost nothing immediately and constrain you considerably later, which makes them worth getting right at build time rather than discovering at scale.
URL structure is the clearest. A structure that made sense at twenty pages becomes awkward at two hundred, and changing it later means a redirect migration with all the risk that carries. Decide the hierarchy before you need it, keep URLs short, stable and descriptive, and avoid embedding anything that will change such as dates, categories that might be reorganised, or a product identifier from a system you may replace.
Pagination and filtering on listing pages is the second. A site that will grow into thousands of items needs a decision about which filter combinations are indexable before there are thousands of them, because retrofitting that control after Google has crawled hundreds of thousands of near-duplicate URLs is considerably harder than preventing it.
And internationalisation, if it is ever likely. Adding a second country or language to a site that assumed one is a structural change. It costs almost nothing to leave room for it in the URL and content model at the start.
None of these are urgent at launch, which is exactly why they get deferred, and all of them are expensive once traffic depends on the structure you chose.
Who should do this work
Technical SEO sits awkwardly between marketing and engineering, which is why it is so often nobody job and so often done badly.
The diagnosis genuinely needs someone who understands search: reading the coverage report, understanding why a page is excluded, knowing which canonical conflicts matter and which are cosmetic. That is a specialist skill and a small one in volume, typically a few hours a month for most sites.
The implementation needs a developer with access to the codebase and the server. Most of the fixes that matter are code or configuration changes rather than things done through a plugin interface, and a marketing agency without development access will produce a list of recommendations that nobody actions.
The failure mode is an SEO supplier who can diagnose but not implement, handing a list to a developer who does not understand the priority, with nobody owning the outcome. If you are buying technical SEO, establish at the outset who will make the changes and who signs off that they worked.
For most businesses the practical answer is a technical review two or three times a year, implemented by whoever maintains the site, with monthly monitoring of the coverage report and Core Web Vitals in between.
In practice
The four things that genuinely matter
In order of how much they affect whether you rank at all.
What technical audits over-report
Several items appear on almost every automated audit and warrant very little attention.
Meta keyword tags. No major search engine has used them in well over a decade. An audit flagging them is telling you about the tool age rather than your site.
Heading hierarchy violations in isolation. Whether a section uses h3 before h4 in a footer changes nothing. A missing or duplicated h1 on a main content page matters; the rest is tidiness.
Image alt text on decorative images. Alt text matters for accessibility and for images carrying meaning. A decorative background flagged as missing alt is noise, and correctly has empty alt.
Low text-to-HTML ratio, which is a metric with no bearing on ranking that appears on audits because it is trivially computable.
And large counts of low-value URL parameters flagged as duplicate content, which usually need a canonical decision rather than a hundred individual fixes.
How to judge an SEO supplier
Ask what they would fix first and why, and listen for whether the answer starts with crawlability and indexing or with a list of cosmetic issues. A supplier who leads with your Search Console coverage report is looking at the right thing. One who leads with a hundred-page tool export has run a tool.
How to prioritise
Work in the order that things stop pages from ranking at all before you work on things that improve pages already ranking.
First, confirm your important pages are indexed. Search Console coverage will tell you, and it is common to find that a meaningful proportion are not, for reasons nobody knew about.
Second, fix anything preventing crawling or serving the wrong canonical, because these waste crawl budget and split signals.
Third, fix Core Web Vitals on your highest-traffic entry pages, using field data rather than lab scores, in the order CLS then LCP then INP because that is roughly cheapest to hardest.
Fourth, add structured data for the entities that matter: the organisation, your services or products, and any genuine FAQs.
Everything else on the audit can wait indefinitely, and in most cases permanently.
In practice
Key takeaways
- Four things matter: crawlability, content present without JavaScript, one canonical version, and field performance.
- A page that is not indexed is not competing. Check Search Console coverage before anything else.
- Meta keywords, decorative alt text and text-to-HTML ratio are audit noise.
- A staging robots file in production is the most catastrophic and most common technical failure.
- Judge an SEO supplier on what they fix first, not on the length of their audit.
Frequently asked
Crawlability and indexing, because it is binary and overrides everything else. A page that is blocked, carries a noindex tag or is unreachable by any link is not competing regardless of quality. Check the Search Console coverage report first; it is common to find a meaningful share of pages excluded for reasons nobody knew about.
A short one focused on indexing, canonicals and field performance is genuinely useful. A hundred-page automated export is not consulting, it is a tool run in seconds, and most of what it lists changes nothing. Judge the supplier on what they say to fix first and why.
It can. If key content only appears after JavaScript executes, some crawlers may not see it, and this matters increasingly for AI retrieval crawlers which frequently execute little or no JavaScript. Server-rendered HTML removes the question. A site can use JavaScript extensively and still be fine provided the content exists in the initial response.
Monthly for Search Console coverage and Core Web Vitals field data, because both degrade quietly and you want to catch a regression within weeks rather than months. A fuller review after any significant change to the site, the platform or the hosting. Continuous auditing is unnecessary for most sites.