Technical SEO is the part of search that gets sold hardest and explained least. Somebody emails, tells you your site has critical technical issues, attaches a PDF full of red warnings, and quotes a monthly fee to make them go away. A few of those warnings genuinely matter. Most are cosmetic, and some refer to things Google has said outright that it ignores. You have no way of telling which is which, because nobody has ever explained what the term actually covers. So here it is, in plain English.
The short version, which the rest of this guide unpacks: technical SEO is the work that lets a search engine find your pages, read them and file them correctly. It is not what the pages say, and it is not who links to you. It is plumbing. Good plumbing does not make a house desirable, but bad plumbing can make it unsellable.
Key takeaways
- Technical SEO is about whether Google can find, read and file your pages, not about what those pages say or how good your business is.
- Crawling, indexing and ranking are three separate stages, and a fault at one of them looks nothing like a fault at another.
- It is a foundation rather than a growth lever: fixing it removes a handicap, it does not create demand.
- The faults that genuinely cost money are blunt ones, like a noindex tag left on after a rebuild, not the subtle items in an automated audit.
- Google Search Console will tell you free of charge whether you have a real technical problem, and most owners have never opened it.
- If your important pages are indexed and the site behaves on a phone, your problem is almost certainly content and competition rather than code.
- Nobody can promise you rankings, and anyone selling technical SEO on that basis is selling you the wrong thing.
Who this guide is for
This is for the owner of a small business website who keeps being told they have technical SEO problems and has no way of judging whether that is true. If you have had the cold email with the red-and-green audit attached, you are the person it was written for. The vocabulary is deliberately opaque, and parts of the industry benefit from keeping it that way.
It assumes no technical knowledge. You do not need to know what an HTTP header is, and by the end you still will not. What you will have is a working picture of what happens between publishing a page and somebody finding it on Google, which is enough to tell a real fault from a scare tactic.
It is less useful if you run a large ecommerce operation with fifty thousand product URLs, because at that scale this becomes a genuine ongoing discipline. One disclosure as well: we build websites, so we have an obvious interest in you worrying about this. That is exactly why the honest answer sits at the top.
What technical SEO actually covers, and what it doesn't
Every conversation about SEO is really about three things bundled under one label. Technical, which is whether a search engine can reach and understand your pages. Content, which is whether those pages answer what somebody typed better than the alternatives. Authority, which is whether the wider web treats you as credible.
The bits that genuinely count as technical
Strip out the jargon and the list is short. How your pages link together and how deep they sit. What your URLs look like. Whether your sitemap is accurate and what your robots.txt file says. Whether you have told Google which version of a page is the real one. Whether the site is secure, works on a phone and loads at a sane speed. And whether anything is accidentally telling search engines to go away. Several of those arrive already sorted on any decent platform, which is why an ongoing technical retainer is a hard sell for a ten-page brochure site.
What gets sold as technical SEO but isn't
Keyword research is not technical SEO. Nor is writing service pages, building links or managing your Business Profile. When a proposal bundles them under one heading it becomes impossible to tell what you are paying for, which is usually the point.
Automated audit tools deserve their own warning. One will happily flag a missing meta keywords tag, which Google abandoned long ago, or complain that a page has two H2 headings, which is not a fault. A red number is a prompt to investigate, never a diagnosis.
Crawling, indexing and ranking are three different things
This is the distinction almost nobody gets told. Getting a page in front of a customer happens in three stages, and each can fail on its own.
Crawling: can Google reach the page
Crawling is discovery. Google follows links from pages it already knows, reads sitemaps, and goes looking for URLs it has not seen. A page that nothing links to and that is missing from your sitemap may simply never be found, which is an absence rather than a penalty. Crawling can also be blocked in robots.txt, deliberately or by accident.
Indexing: is Google willing to keep it
Being crawled is not the same as being kept. Google may decline to store a page because it carries a noindex instruction, because it near-duplicates another page, or because it judges the page too thin to be worth holding. On small sites that last reason is the most common by far, and no amount of technical work fixes it.
Ranking: where you sit against everyone else
Ranking is the competition. An indexed page competes for position against every other indexed page that could answer the same query, weighed on relevance, quality, authority and where the searcher is standing. Technical work influences this only indirectly. A well-structured site is easier to rank than a chaotic one, but it does not supply the thing rankings are made of.
A page that is not crawled cannot be indexed. A page that is not indexed cannot rank. And a page that is indexed and still gets no traffic does not have a technical problem, it has a competition problem.
Why the distinction changes what you should buy
Name the stage and you name the fix. Nothing indexed is an emergency, usually one setting. Some pages indexed and some not is normally a quality issue wearing a technical costume. Everything indexed but no traffic is competition. Ask any supplier which stage is failing and how they intend to show you.
Site structure, internal linking and URLs
Structure is a statement about what matters
Search engines discover pages by following links, so a page nothing links to may as well not exist, and customers behave the same way. Anything important should be reachable in two or three clicks and linked from more than one place, because depth is a proxy for importance. If your main service page sits buried under a blog category, you have told Google it is a minor item.
What goes wrong is usually growth without pruning. A page gets built for a campaign, the campaign ends, the page stays. Three years later four pages half-cover the same service, all competing with each other. The fix is editorial: merge them into one strong page and redirect the rest.
Internal links and URLs
An internal link tells a search engine that a page exists and that you consider it relevant to the words in the link. Use text that describes the destination, so "bathroom fitting in Chelmsford" rather than "click here". Link from your articles into your service pages deliberately, because advice content that points nowhere is pleasant and useless.
A good URL is short, lowercase, hyphenated and descriptive, so /services/bathroom-fitting does the job. Dates and long parameter strings are noise. More important: once a URL has been published for a while, leave it alone. Changing it means every existing link now depends on a redirect, and redirects are a repair rather than an upgrade.
Sitemaps, robots.txt and canonical tags
These are the files and tags that talk directly to search engines: the most quoted items in any audit, the least understood by the people receiving one, and the cause of the most expensive mistakes in this subject.
The XML sitemap
A sitemap is a machine-readable list of the URLs you want search engines to know about. It is a suggestion, not an instruction: listing a page does not force Google to index it, and leaving one out does not hide it. Most platforms generate one automatically, so the common fault is a stale sitemap full of URLs that redirect or error.
robots.txt, and the mistake everyone makes with it
The robots.txt file sits at the root of your domain and tells crawlers which paths they may fetch. It is useful for keeping them out of admin areas, and it is also, reliably, the file that takes entire websites out of Google.
The mistake is assuming that blocking a page removes it from search results. Blocking stops Google fetching the page, so it can no longer read the noindex instruction that would have removed it. If you want a page gone, let Google crawl it and use noindex.
Canonical tags and the duplicate content question
Duplicate content generates more unnecessary fear than anything else in SEO. There is no penalty for having similar pages. What happens is mundane: when Google sees several URLs with substantially the same content it picks one and ignores the others. If it picks the one you did not want, you lose.
A canonical tag is how you cast a vote, a line of code naming the proper address for this content. Duplicates appear without anyone creating them, such as the same page with and without a trailing slash. The riskier version is the one you made on purpose: ten location pages identical apart from a swapped town name.
The page-level basics: HTTPS, mobile, speed and structured data
HTTPS and mobile-first indexing
Three of the four things in this section are hygiene: you want them adequate, and the gap between adequate and perfect is worth less than a better service page. HTTPS is the clearest example. It encrypts the connection between visitor and site, browsers now warn people away from pages without it, and certificates are free from almost every host.
Mobile-first indexing means Google indexes the mobile version of your site. Not the desktop version with a mobile check afterwards: the mobile version is the version. So if a block of text gets stripped out at phone width to keep the design tidy, Google may never see it. Collapsed accordions are fine, because the content is still in the page.
Page speed and Core Web Vitals
Core Web Vitals measures real user experience with three numbers: how long the main content takes to appear, how quickly the page responds when tapped, and how much the layout jumps about while loading. Google treats these as tie-breakers rather than primary factors, so a fast page with weak content will not beat a slower page that answers the question properly.
The commercial argument is stronger anyway, because slow pages lose visitors before search engines get a say. The causes are usually boring: huge uncompressed images, scripts loading before anything appears, a theme carrying features nobody uses.
Structured data
Structured data is a block of code stating facts about a page in a format machines read without ambiguity: this is a local business, these are its hours, this is a product with a price. You are not adding new information, you are removing the need for Google to infer it.
It makes you eligible for richer-looking results such as star ratings and FAQ dropdowns. It does not make you rank higher, and Google has said so repeatedly. The useful types are few: LocalBusiness, Organization, FAQPage and Product or Service. Marking up things that are not really there is worse than doing nothing.
What actually breaks, and how you'd spot it
Everything above is theory. In practice the faults that cost real money are a short, repetitive list, and almost all arrive on the same day: the day a new website goes live. Rebuilds change every URL, setting and file at once, and nobody checks the invisible ones. The table below covers the symptoms owners describe.
| Symptom | Likely cause | How to check |
|---|---|---|
| The whole site disappeared from Google after a redesign | A noindex instruction or robots.txt block carried over from the staging site | Read yourdomain.co.uk/robots.txt, then check the Pages report for URLs excluded by a noindex tag |
| A new page never appears, even when you search its exact title | Not crawled yet, or nothing on the site links to it | Paste the URL into the URL Inspection tool in Search Console and read the status |
| Traffic dropped sharply the week a new site went live | Old URLs were not redirected to their new equivalents | Look for a spike in not-found errors, and try a handful of old URLs by hand |
| Google keeps showing an old title or an outdated version of a page | A canonical tag pointing at the wrong URL, or the page has not been recrawled | URL Inspection shows the Google-selected canonical beside the one you declared |
| One page ranks and the near-identical one beside it never does | Duplicate content, with Google keeping one version and ignoring the other | Search Console lists the ignored page as a duplicate where Google chose a different canonical |
| Pages are indexed, load quickly, and still get no traffic | Not a technical fault. The pages are not competitive for anything people search | Performance report: impressions without clicks means you appear but too far down |
The noindex left on after a rebuild
While a site is being built it usually carries a noindex instruction so the half-finished version never turns up in search. The failure is forgetting to remove it at launch, and the site then quietly ceases to exist as far as Google is concerned. Nothing looks wrong: every page loads, the forms work, and enquiries just stop.
Blocked resources and redirect chains
Google renders your pages roughly the way a browser does, so it needs the stylesheets and scripts that make them work. Block those in robots.txt and Google sees a broken skeleton. This one is subtle because the site works perfectly for humans, and the URL Inspection tool will show you how Google actually rendered it.
Redirects are the other migration hazard. Chains build up, where the 2019 URL points at the 2022 one, which points at the 2024 one. The lazier fault is redirecting everything to the homepage, which avoids error pages and loses the visitor.
Orphan pages
An orphan page is one that nothing on your site links to. It exists, it may even be in the sitemap, but there is no route to it. They come from history: a campaign page, a service you stopped promoting, a landing page from an old agency. If it still matters, link to it properly. If not, remove it and redirect it.
Is it technical, or is it content and competition?
This is the question worth answering before you spend anything, and for most small business websites the answer is content and competition. The foundation is adequate. The site produces no enquiries because the pages do not say enough and nothing much links to them.
That answer is unpopular because it implies work rather than a purchase. A technical fix is a one-off invoice and a report full of green ticks. Better content is slower, harder, and has no tidy completion date. It is also the thing that moves the needle.
The half-hour check that settles it
You can answer this yourself today without buying anything. Set up Google Search Console, which needs one verification step and is free, then work through four things in order and write down what you find.
- Are your important pages indexed? Run URL Inspection on your homepage and top three service pages. If each reports that the URL is on Google, crawling and indexing are working.
- Does the Pages report show mass exclusions? A handful is normal. Most of your pages excluded, particularly for noindex or robots.txt reasons, is a genuine problem.
- Are you getting impressions without clicks? Impressions mean you are appearing. Impressions with almost no clicks means you appear too far down to be seen, which is competition rather than code.
- Does the site work on a phone? Open it on mobile data and try to find your prices and phone number. If that takes more than a few seconds you have found something no audit tool would flag.
Four outcomes, four responses. Nothing indexed is an emergency and usually one setting. Most things indexed with a few gaps means the technical side is fine and the gaps are quality. Impressions but no clicks means your pages are not competitive. No impressions at all means nobody is searching for what those pages target, which is a positioning problem.
What a content and competition problem looks like
It looks like a service page of two hundred words that could belong to any business in the country. It looks like a homepage that never names the towns you serve, or a business with four reviews competing against one with ninety. None of that is fixed by a faster server.
If Search Console is unfamiliar territory, start there rather than with an agency. Our walkthrough of Google Search Console covers the exact reports used in that check, and the guide to the Google tools every small business needs explains how it sits alongside Analytics and your Business Profile. Both cost nothing.
Common mistakes
These come up constantly, and each one costs either money or momentum. Most are avoidable with a single check rather than a project.
- Buying technical SEO before checking whether anything is broken. Ten minutes in Search Console usually answers it, free.
- Treating an audit score as a diagnosis. Tools flag issues by configuration, not by impact.
- Blocking pages in robots.txt to remove them from Google. That prevents Google reading the noindex that would have removed them.
- Launching a rebuild without checking the noindex setting. The most expensive single mistake here, and it is one checkbox.
- Redirecting every old URL to the homepage. It avoids error pages and loses the visitor.
- Changing URLs because they look untidy. Tidy URLs are a build-time decision, not a maintenance activity.
- Publishing near-identical location pages. Swapping the town name across ten pages produces nine that Google ignores.
- Chasing a perfect speed score. Compress the images, remove the widgets nobody uses, then stop.
- Never checking anything again after launch. A plugin update can reintroduce a fault that was fixed two years ago.
There is a pattern in that list. Almost every genuine technical problem is a blunt on-or-off failure caused by a change somebody made, not a slow decline caused by neglecting an optimisation. Those are easy to find once you know where to look.
So the moment to be careful is any moment of change: new site, new host, new plugin, new developer. Those are the events that break things, and a fifteen-minute check afterwards is worth more than a year of monthly reports on a site nobody has touched.
A sensible order to work through an audit
If you want to check your own site properly, do it in this order. The catastrophic possibilities come first and the cosmetic ones last, so you can stop at any point and still have had the value.
- Set up Google Search Console. Nothing else here can be answered without it, and it is free. Give it a few days to populate.
- Read your robots.txt file. Look for anything disallowing the whole site or blocking directories that hold your design files. One minute, and it rules out the worst case.
- Inspect your five most important URLs. Homepage, service pages, contact. If any is not on Google, the reason given is your first job and probably your only urgent one.
- Scan the Pages report for patterns. A few exclusions are normal. Large groups excluded for the same reason are a real signal.
- Check the site on your own phone. Anything missing on mobile that exists on desktop may as well not be published.
- Test the speed of a page that gets traffic. Read the mobile results. If images top the recommendations, which they usually do, that is a straightforward job.
- Walk your own structure. Click from the homepage to every page you consider important. Anything you cannot reach in three clicks needs linking properly or removing.
- Check old URLs after any migration. Errors instead of sensible redirects mean you have lost whatever those pages had earned.
- Look at duplicates last. Near-identical and thin location pages are editorial work, and they can wait.
Most owners who work through that find one or two things worth fixing and nothing resembling the emergency they were sold. That is a useful outcome either way, because it turns a vague anxiety into a specific job or a clear conscience.
Do it once properly, then again after any significant change. Beyond that, every six months is plenty. Technical SEO is not a treadmill unless somebody is charging you to run on one.
Frequently asked questions
What is technical SEO in simple terms?
Does my small business website actually need technical SEO?
What is the difference between crawling and indexing?
My pages are not showing up in Google. Is that a technical problem?
How much do Core Web Vitals really matter?
Can I do technical SEO myself, or do I need a specialist?
Will adding structured data make me rank higher?
How often should technical SEO be checked?
Where this fits
Technical SEO is a foundation, not a growth lever. Getting it right stops your site being held back. It does not, on its own, make you rank, and any supplier who frames it that way is either confused or hoping you are.
The practical order runs the opposite way from how it gets sold. Confirm the technical floor is sound, which is usually an afternoon rather than a retainer. Then spend your effort on pages that answer what customers ask, on your local presence, and on the reviews that make you look worth ringing.
If you want a second opinion on whether your site has a real technical problem, we will tell you straight, including when the answer is that you do not. Our SEO work starts with foundations and evidence rather than scores, and our web design builds the basics in from the start. If you would rather just talk it through, get in touch.
