Technical SEO is the part of search engine optimisation that decides whether Google can reach your pages, read them properly and pick the right version to show. When that layer is broken, the rest of your SEO has little to work with: a well-written service page that Google never indexes cannot rank for anything. I find these problems on UK business websites, fix them or write the fixes up for your developer, and confirm in Search Console that Google has picked up each change.
What gets fixed, and what that changes for your business
Most technical faults show up as a gap between the pages you have and the pages Google knows about. You publish new service pages and, weeks later, the Page indexing report in Search Console lists half of them as “Crawled – currently not indexed”. Google shows a filtered or parameter version of a page instead of the clean one. A rebuild last year quietly broke the URLs other sites used to link to.
Once those faults are fixed, the pages you care about are the ones Google stores and can show. Links and other signals collect on one version of each page instead of being split between copies, and Google’s visits go to pages that matter rather than to filter combinations, retired URLs and test pages. None of this makes a page rank by itself. It removes the reasons a good page cannot.
Who this service suits
It suits UK businesses with an established website that should be bringing in enquiries or sales and is not, where the cause looks structural rather than a matter of wording. Typical signs:
- Important pages are still missing from Google weeks after they went live.
- Search Console reports many more excluded or duplicate URLs than the site has real pages.
- Organic traffic fell after a redesign, a change of platform or a plugin update.
- A shop’s filters and sort options have produced a mass of near-identical URLs.
- You have a developer who can make changes, but nobody who can say which changes matter for search.
It is the wrong place to start if your site is small, recent and already indexed, or if your pages are indexed but rank for nothing useful. That points to what each page targets and says, which is on-page SEO work. If you cannot tell which kind of problem you have, a full SEO audit looks at the technical set-up, content and links together and shows where your budget should go first.
What the work covers
Crawling and access
I look for anything that stops Googlebot reaching your pages: robots.txt rules that block whole folders, server errors when the site is busy, pages behind a login, and crawl traps such as calendars or filter combinations that generate new URLs without end. On large sites I also use server logs to see how Google spends its visits. On a small brochure site crawl budget is rarely the problem, and I will tell you so rather than spend your money on it.
Indexing
Next comes which pages Google has chosen to index and why it has left others out. A stray noindex tag carried over from a staging site can keep a whole section out of search. So can soft 404s, pages that return a normal status code but look empty to Google. I compare the sitemap, a full crawl and Search Console so every important URL has a known status and a reason.
Canonicals and duplicate URLs
The same page can often be reached at several addresses: with and without www, over http and https, with and without a trailing slash, or with tracking parameters attached. Each should resolve to one version, and the canonical tag on every page has to agree with your redirects, internal links and sitemap. When those signals contradict each other, Google chooses a version for itself, and it is not always the one you would pick.
Redirects and status codes
An old URL that still has links pointing at it should return a single 301 redirect to the closest live page. I look for chains of several hops, loops, old pages all sent to the home page (which Google may treat as soft 404s) and broken internal links. If you have a list of old and new addresses, my redirect map builder turns it into server rules and flags chains before they go live.
Site structure and internal links
The way pages link to one another tells Google which pages matter most and how they relate. I map how many clicks each important page sits from the home page, find orphan pages that nothing links to, and check that navigation, breadcrumbs and URL folders follow the way your customers think about what you sell. On a site that has grown one page at a time, fixing the structure helps many pages at once, which is why I often start here.
Pages built with JavaScript
Some sites build their content in the browser with JavaScript. Google handles that in a separate stage called rendering, and anything that fails there is invisible to search, so I compare the raw HTML with the rendered page. UK sites carry a particular risk here. A cookie consent tool that holds scripts back until a visitor clicks Accept holds them back from Googlebot too, because Googlebot never clicks anything. If one of those scripts loads your product list or your menu, Google does not see it.
XML sitemaps
Your XML sitemap should list only canonical, indexable pages that return a 200 status. Plugin-generated sitemaps can also include redirected URLs, tag archives and attachment pages, which weakens the file as a statement of what you want indexed. I clean it up and submit it in Search Console, split by page type where that shows which kinds of page Google is struggling with.
Mobile versions and HTTPS
Google indexes the mobile version of each page, so content or links that only appear on desktop may as well not exist. I check that both versions carry the same content, that every page loads over HTTPS without mixed-content warnings, and that the security certificate covers every subdomain you use.
Where speed and structured data fit
I record Core Web Vitals failures during the review and fix those caused by the problems above, such as a plugin loading scripts on every page. A full speed project, covering templates, images, hosting and third-party tags, is separate. Structured data works the same way: I check existing markup for errors, while building new markup for rich results is covered by my schema markup service.
How a technical SEO project runs
- Access and a short call. I ask for read access to Search Console and Google Analytics 4, and the dates of recent changes such as a redesign, a new plugin or a hosting move. Those dates often explain what the data shows.
- Crawl and compare. I crawl the whole site as Googlebot would, then set the results beside your sitemap, Search Console and any server logs. Most faults sit where those sources disagree.
- Prioritise. Each issue gets the URLs it affects, its cause, the fix and the effort involved, ranked by how far it holds back the pages that earn you money. A fault on your main service pages comes before one on old blog tags.
- Fix. Where I have access to the content management system, as on most WordPress sites, I make the changes myself. Where a developer owns the code, I write each fix as a ticket stating the exact change and how to test it.
- Verify. After each release I re-crawl, inspect the key URLs in Search Console, start its validation on the fixed issues and watch indexing over the following weeks. A fix is finished when Google has picked it up, not when the code ships.
Technical problems common on UK business sites
These are the faults I check for first, because they are easy to cause and costly to leave in place.
- Search engines still switched off after launch. WordPress has a setting that asks search engines not to index the site. It is ticked during the build, and if nobody unticks it at go-live, the finished site can stay out of Google for months.
- Staging copies in the index. A test version on a subdomain, left open to crawlers, competes with the live site.
- Both the .co.uk and the .com serving the site. Owning both domains is sensible. Serving the full site on each, instead of redirecting one to the other, gives Google two copies of every page.
- Town pages that differ only by name. Trades and service firms often publish a page per town with the same text and a new place name. Google tends to index a few and ignore the rest, and its spam policies list pages aimed at individual cities or regions among their examples of doorway pages.
- Filters and toggles on online shops. Size, colour and price filters, and on trade suppliers’ sites a switch between prices with and without VAT, can each add a URL parameter. Left unmanaged, they create far more crawlable addresses than there are products.
- Redirects lost in a rebuild. A new site goes live with a new URL pattern and no redirects from the old one, so years of links point at error pages. Planning that move is the job of website migration SEO; if the damage is already done, recovering the old URLs is part of this work.
What you have at the end
- An issue log of every fault with the URLs affected, priority, fix and owner, kept current as fixes go live.
- Developer tickets for anything I cannot change myself.
- A dated change log, so later movements in traffic can be read against what changed and when.
- A before-and-after comparison of the crawl and of the indexing figures in Search Console.
- A short plain-English summary of what was wrong, what has been fixed and what still needs attention.
Where to start
If pages are missing from Google, or you suspect the way the site is built is holding it back, start with a free SEO audit of your site. Send me the address and a line about what you have noticed. I will tell you which technical problems I would fix first, and say plainly if technical work is not where your money should go.