Technical SEO attracts disproportionate budget because it is measurable, produces satisfying numeric scores and feels like engineering. That combination makes it easy to sell and easy to over-invest in, particularly to businesses that would rather fix a number than write a page.
The honest framing is that technical work is necessary and rarely sufficient. It removes the reasons a page cannot rank. It does not give it a reason to. This article covers the parts that genuinely matter for a local business site, in order of impact, and the parts that consume budget without changing anything.
Automated audits return hundreds of items. On a typical local business site, four questions catch essentially every problem that affects visibility.
| Check | How to verify | Why it matters |
|---|---|---|
| Can it be reached? | robots.txt read in full, status codes on the top 50 URLs | Blocked or broken pages cannot rank, whatever else is true |
| Has it been crawled? | Crawl log by section | Turns "why is this not indexed" from a guess into a diagnosis |
| Is it indexed, and under which URL? | Submitted vs indexed ratio; canonical inspection | Duplication and self-canonicalisation errors are the most expensive class |
| Does it render? | Disable JavaScript; check the served HTML | Content the crawler never sees cannot be evaluated |
Submitted URLs against indexed URLs. Above 85% on a local business site is healthy. At 50%, you have content Google has seen and declined - which is a content problem wearing a technical costume, and no amount of tag fixing will change it.
Page speed influences rankings modestly and conversion considerably. Both are worth acting on; conflating them leads to expensive work aimed at the wrong outcome.
The practical target is not a lab score. It is the time until a user on a mobile connection sees something useful. Getting that from six seconds to two and a half changes how many people stay. Getting a synthetic score from 78 to 94 usually changes nothing measurable.
Three causes account for most of the problem on local business sites:
Uncompressed, unsized, and far larger than the space they occupy. Almost always the single biggest win.
Chat widgets, maps, ad pixels, cookie banners. Each one blocks rendering; together they dominate.
Web fonts loaded without a fallback strategy leave text invisible for seconds on slow connections.
Measure with real-user data rather than laboratory tools, and fix only the templates that carry traffic. Optimising a page nobody visits is a satisfying way to spend a day and produces nothing.
Structured data does not improve rankings. It changes how your result is displayed — stars, prices, availability, FAQ expansions, breadcrumbs — and appearance drives click-through, which is worth real money on traffic you already earn.
For a local business, four types cover almost everything worth marking up: the organisation or local business itself with correct address and hours; products with price and availability if you sell online; frequently asked questions where they genuinely exist on the page; and review data where you legitimately have it.
Two warnings. Marking up content that is not visible on the page is a violation and it does get caught. And stale structured data is worse than none: a price or availability figure that no longer matches what the visitor finds converts a click into a disappointment, and you paid attention and quality signal for it.
That second point is more common than it sounds on sites with aggressive caching, where the markup reflects a value the template layer stored rather than the current state. It is worth checking directly a few times a year: search for ten of your own pages and compare what the result shows against what the page says.
Being specific about this saves more money than most positive recommendations.
Chasing a perfect audit score. The last 20% of items in any automated report are almost entirely cosmetic. Nobody has ever gained a position from resolving a "missing alt attribute on a decorative image" warning.
Micro-optimising Core Web Vitals past the threshold. Once you are comfortably inside the recommended ranges, further work has no ranking effect and marginal conversion effect.
Rebuilding a working site for technical reasons alone. A migration always costs traffic temporarily and sometimes permanently. Unless the platform genuinely blocks the work, improving what exists is cheaper and safer.
Aggressive parameter blocking on small sites. Crawl budget management matters on large catalogues. On a fifty-page site it is solving a problem you do not have.
Disavowing links. Rarely appropriate now. Search engines discount most low-quality links automatically, and the tool can do damage if used casually.
Duplication is the most expensive technical category on local business sites and the one most often misdiagnosed, because the symptom is technical and the cause usually is not.
It arrives in four shapes. URL variants - the same page reachable with and without a trailing slash, with and without www, over http and https, with tracking parameters attached. This one is genuinely technical and genuinely easy: pick one form, redirect the rest, and enforce it. Template duplication - the district or service pages that differ only by a place name. Pagination and filters generating endless near-identical listings. And self-competition, where two pages written months apart target the same intent in different words.
Only the first is solved with configuration. The other three are decisions about what should exist. Twenty district pages built from one template are not a canonical problem; they are twenty pages that should have been three. Two service pages competing for the same query are not a tagging problem; one of them should be merged into the other and redirected.
The reason this matters for budget is that duplication is usually handed to a developer, who correctly implements canonicals and reports the task complete - and nothing improves, because the underlying situation is unchanged. The pages still say the same thing, the authority is still split, and the canonical tag has simply told Google which of two weak pages to prefer.
The diagnostic is straightforward. For each query where you underperform, check which of your URLs ranks and whether it is stable week to week. A position that oscillates between two of your own pages is self-competition, and consolidating them typically produces a page that outranks both predecessors within a couple of months.
Technical SEO recommendations fail most often at the handover, not at the diagnosis. A list of findings in SEO vocabulary lands on a developer who has other priorities, no context and no way to judge urgency - and it stays in the backlog.
Four things make the difference. State the change, not the problem. "Add a self-referencing canonical to the service template" is actionable; "canonicalisation issues detected" is not. Give the affected URLs, not a count. Say what breaks if it is not done, in business terms rather than in metrics - "these twelve pages cannot appear in search results at all" gets scheduled; "suboptimal indexation" does not. And define how you will verify it, so the ticket has a closing condition that is not simply "deployed".
The last one matters more than it appears. A change that is deployed but not verified is a change that may or may not have happened - and in our experience roughly one in five technical fixes does not survive contact with the production environment, usually because of caching, an overriding plugin, or a template that was not the one being edited. Checking the live page yourself after deployment takes two minutes and catches all three.
Beyond these, two things reliably repay attention. Sitemap hygiene: only indexable URLs, honest modification dates, split by content type so that a problem can be located in minutes rather than hours. And a deployment check: a short list run after every release confirming that robots directives, canonicals and key pages are unchanged. Most serious technical incidents we are called about are deployment accidents that nobody noticed for weeks.
The most useful shift in technical SEO practice is to stop trusting tool output and start watching behaviour.
A tool tells you a page is indexable. The crawl log tells you whether a bot actually visited it, when, and what response it got. A tool tells you the sitemap is valid. The submitted-versus-indexed ratio tells you whether the pages in it were accepted. A tool gives a performance score. Real user data tells you what visitors experienced.
This matters because the two frequently disagree, and when they do, observation is right. A page can pass every technical check and never be crawled because nothing links to it. A site can score well in a laboratory and be slow on the connections its actual customers use.
Setting up the observational layer costs nothing: the indexing log, search analytics and rank tracking in the free layer of Semalt share one period and one domain, which is what makes cause and effect legible rather than inferred.
Crawl log, indexing status and search analytics in one free account. It turns technical SEO from a checklist into something you can verify.
Sign in to Semalt See Fast IndexingModestly important, and considerably more important for conversion. Fix it, but justify it on the conversion argument.
No. It improves how your result is displayed, which improves click-through on traffic you already have.
No. Most of it is cosmetic. Work through the four core checks first and treat the rest as optional housekeeping.
Not necessarily, but it adds a permanent verification burden: every release needs someone to confirm content is present in the served HTML.
A short check after every deployment, fifteen minutes weekly, two hours quarterly, and a full review annually or on any rebuild.
Technical SEO deserves attention proportionate to what it does: it removes obstacles. A site that cannot be crawled, indexed or rendered will not rank regardless of how good its content is — and a site that is technically flawless will still not rank if it says nothing worth reading.
Run the four checks, fix what they surface, then move the budget to the pages themselves. And verify by watching behaviour rather than by reading scores: connect your domain and look at whether bots are actually visiting the pages you care about. That single observation resolves more arguments than any audit report.
If you would like the four checks run on your site with a prioritised list of what genuinely matters — and an explicit list of what we would ignore — get in touch. The initial audit is free and delivered within 48 hours.
Free analytics for Google Search, SERP rankings and AI answers - plus fast indexing for your new pages.
Sign in to Semalt semalt.comGet in touch for a free audit
