Technical SEO
You can write the best page in your sector and still lose to a worse one, because a search engine cannot crawl yours, cannot render it, sees three copies of it, or gives up before the page finishes loading. None of that is visible from the front end. The site looks fine.
What is included
- A full technical crawl of the site, sized to the number of URLs
- A non-rendering check of what crawlers actually receive in the HTML response
- Indexation review against Search Console, including canonicals and parameters
- Core Web Vitals measurement on real mobile conditions
- Structured data validation against what is visible on the page
On this page
- What does a technical SEO company or agency actually do?
- Why do most technical SEO audits never get implemented?
- What does a technical SEO audit cover?
- Which technical problems actually cost you traffic, and which are just audit noise?
- What are Core Web Vitals, and how much do they matter for SEO?
- What is the JavaScript rendering problem, and why do most audits miss it?
- How can I check my own site in thirty seconds?
- Did our own website have this problem?
- Which technical SEO problems belong to which kind of site?
- Should you buy the audit, the implementation, or both?
- What is the difference between a technical SEO agency, consultant and specialist?
- Why is technical SEO different for software and SaaS companies?
- How do you judge a technical SEO company, consultant or specialist?
- What drives the cost of technical SEO?
- When is technical SEO the wrong first step?
What does a technical SEO company or agency actually do?
A technical SEO company makes a website readable and trustworthy to search engines. It checks that pages can be crawled, indexed and rendered, that structure and speed hold up, and that structured data and redirects are right, then fixes what is wrong. The test of any supplier is whether the fixes ship.
“Technical SEO services”, “technical SEO company” and “tech SEO agency” describe the same work. What differs is whether the supplier stops at a report or changes the site. Many can only write recommendations because they do not build websites. Here the finding and the fix sit with the same people. If you need only the diagnosis, an SEO audit service is the narrower thing to buy.
This layer sits underneath everything else in search. Content written for a page that cannot be indexed earns nothing, and the technical layer is where server and platform problems surface, so it is usually the first thing to check and the last thing a business thinks to ask about.
Why do most technical SEO audits never get implemented?
Because the person who wrote the audit is not the person who has to act on it. A technical SEO audit is a relatively easy thing to produce: run a crawler, export the warnings, add commentary, deliver a 60-page PDF. Then the PDF goes to your developer, who is busy shipping features, who did not commission it, who disagrees with a third of it, and who has no way to judge which items matter. Six months later most of it is undone and both sides quietly blame the other.
We are the developer. Saurav Dhoju builds websites and business software; Bikram Sah runs the search side. An audit finding is a ticket in the same small team's backlog, not an email to somebody else's.
That changes what an audit is worth. A list of problems has value only if somebody solves them — which is also why technical work is included in the SEO retainer plans from Growth upwards rather than sold as a document and left there.
What does a technical SEO audit cover?
Ten areas, checked in this order because the early ones decide whether the later ones matter: crawlability, indexation, rendering, architecture and internal linking, Core Web Vitals, mobile and accessibility, structured data, redirects, hreflang and log files. There is no point tuning performance on a page that cannot be indexed.
- Crawlability. Robots.txt directives, crawl budget, orphaned pages, crawl traps, faceted navigation generating infinite URLs — the usual culprit on an e-commerce catalogue — and whether the pages you care about are actually reachable from anywhere.
- Indexation and canonicals. What is indexed against what should be, canonical tags pointing where they should, parameter handling, pagination, www and non-www resolution, HTTP to HTTPS, trailing slashes, and duplicate content generated by templates rather than by people.
- JavaScript rendering. The one most audits miss entirely, and the deepest hole a modern site can be in. It has its own section below.
- Site architecture and internal linking. Click depth from the homepage, how link equity flows, whether your commercial pages are supported or stranded, and whether several thin pages are competing for the same term instead of one strong page owning it.
- Core Web Vitals and performance. Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift. Image handling, render-blocking resources, font loading, caching, third-party scripts. Measured on real mobile conditions, not on a desktop connection.
- Mobile and accessibility. Responsive behaviour, tap target sizing, viewport configuration, and accessibility fundamentals — semantic structure, contrast, keyboard navigation. Better for users, and increasingly part of how pages are assessed. The same checks decide whether a visitor on a phone actually gets as far as the enquiry form.
- Structured data. What exists, whether it validates, whether it matches what is visible on the page, and what is missing. Organisation, LocalBusiness, Service, Product, Article, FAQPage, BreadcrumbList — the LocalBusiness markup in particular is what ties the site to your Google Business Profile and map pack presence.
- Redirects and migration safety. Redirect chains and loops, 404s that used to be pages with links pointing at them, and — where a migration is planned — a full URL map before anything moves.
- International and hreflang. Where a site targets more than one country or language, whether the signals are consistent and reciprocal. Wrong hreflang is worse than none.
- Log file analysis. Where the data exists, what search engines are actually crawling, how often, and how much budget is being spent on pages that do not matter.
Which technical problems actually cost you traffic, and which are just audit noise?
Four of the findings in a typical audit are worth dropping other work for; the rest of the report is usually padding that makes the document look thorough. This is the triage we apply before anything reaches a backlog, and it is why our reports are shorter than the ones they replace.
| Finding | How much it really matters | Why |
|---|---|---|
| Pages that cannot be indexed | Critical. Nothing else on the list matters until it is fixed. | A noindex tag left over from staging, or a robots.txt disallow nobody removed at launch, takes the page out of search entirely. The content can be perfect and it will still earn you nothing. |
| Content only drawn by JavaScript | Critical, and the most commonly missed. | A crawler that does not render receives an empty shell. Google usually copes; many AI and answer-engine crawlers do not, and neither do most social preview bots. |
| Canonicals pointing at the wrong URL | Serious. It concentrates your authority on a page you did not choose. | A template-level canonical error can tell a search engine that every page in a section is a copy of one page. The traffic does not decline gradually — it moves. |
| The site is unusable on a phone | Serious, and it costs you enquiries before it costs you rankings. | Mobile is what gets assessed, and it is where most first visits arrive. A page that is hard to tap or slow to load on a phone loses the visitor whether or not it ranks, which makes it a conversion problem as much as a technical one. |
| A server that is slow or intermittently failing | Serious. It puts a ceiling on everything else you do. | Timeouts and 5xx responses tell a crawler to come back later, and it obliges by coming back less often. A host that struggles under ordinary traffic is the one finding here that no amount of on-page work can compensate for. |
| Meta keywords missing | Ignore it. No search engine has used the tag for well over a decade. | It appears in audit exports because the tool still checks for it, not because it does anything. Its presence in a report tells you more about the report than about your site. |
| Heading-order warnings and long meta descriptions | Mostly noise. Fix them when you are in the file anyway. | An h3 following an h1, or a handful of descriptions that get truncated in the results, will not change what ranks. Hundreds of these are what pad a report to sixty pages and bury the four findings that mattered. |
What are Core Web Vitals, and how much do they matter for SEO?
Core Web Vitals are Google’s measures of real-world page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. They are a ranking signal, but a modest one. Relevance outweighs them, so they decide close contests more than they rescue weak pages.
Google publishes a threshold for each: a main element loading within 2.5 seconds, interactions responding within 200 milliseconds, and layout shift of 0.1 or less, judged across real visits rather than one test run. What the Core Web Vitals measure is covered in its own guide, including how to read the reports.
In practice the causes are rarely mysterious: oversized images, render-blocking scripts, late-loading fonts and third-party tags. The reason to fix them is as much the visitor as the ranking. A page that stutters on a phone loses the enquiry before Google has any say.
What is the JavaScript rendering problem, and why do most audits miss it?
Modern websites are frequently built so that the server sends an almost empty HTML shell, and JavaScript then draws the page in the browser. To a person it looks identical. To a crawler it can be the difference between a full page and nothing at all — and most audits never check, because the front end looks fine.
Google does render JavaScript, but rendering is queued, budgeted and slower than crawling raw HTML. On a large site it can be applied inconsistently or with significant delay. And many other consumers of your site do not render at all: a large share of AI and answer-engine crawlers, social preview bots, and a number of third-party SEO tools simply read the HTML response and move on. That is why this single issue sits underneath most AI search and answer engine visibility problems we are asked to solve.
How can I check my own site in thirty seconds?
Open the page, view source — the actual view-source, not the inspector — and search for a sentence you can see on screen. If it is not in the source, it was drawn by JavaScript.
Did our own website have this problem?
Yes. In September 2026 we audited our own website properly for the first time. Every one of the 47 URLs in our sitemap returned byte-identical HTML to a non-rendering crawler: the same title, the same meta description, no h1 at all, fifteen words of body text, and no structured data anywhere.
Forty-seven pages that looked like one page. On a site whose services include search visibility.
We fixed it, and we will show you the before and after, alongside the rest of what we have built. We are telling you this because the alternative — quietly not mentioning it — would make everything else on this page less believable, and because it is a genuinely common failure that almost nobody checks for. If your site was built in the last few years on a modern framework, it is worth thirty seconds of your time to look.
The point
We fixed it, and we will show you the before and after, alongside the rest of what we have built.
Which technical SEO problems belong to which kind of site?
Technical problems cluster by type of site. A planned rebuild risks lost URLs, an online shop generates duplicate and filter pages, a multi-country site needs consistent language signals, and a software site tends to hide content behind JavaScript. Each has a fuller treatment on its own page.
| Kind of site | Where the technical problems usually sit | Fuller treatment |
|---|---|---|
| A site about to be redesigned, replatformed or moved to a new domain | URL maps, 301 redirects, canonicals, staging directives left switched on, and pages that earn links disappearing. | Website migration SEO |
| An online shop with categories, filters and a large catalogue | Faceted navigation, parameter URLs, duplicate product titles generated by templates, and out-of-stock pages. Online shops and retailers have their own page. | Ecommerce SEO |
| A site serving more than one country or language | hreflang that is missing or not reciprocal, mixed-language URLs, and the wrong country page appearing in results. | International SEO |
| A software or SaaS marketing site | Content drawn by JavaScript, an application shell with little in the HTML, documentation on a separate subdomain. Software and B2B tech covers the buyer’s side. | This page: the fix is usually a change to the application itself |
| A site where you only want to know what is wrong | Anything, ranked by likely effect, with the evidence for each finding and a list of what to leave alone. | An SEO audit |
Should you buy the audit, the implementation, or both?
Three ways to work, depending on who does the fixing. Most clients take the second, because the audit is not the point — a list of problems has value only when somebody closes the tickets. The third suits businesses with developers already in place who need specifications rather than hands.
| Option | What it means |
|---|---|
| Audit only | We produce the findings, prioritised by likely impact rather than by tool severity, with enough technical specificity for your developer to act without a follow-up call. Includes a working session with your team to walk through it. |
| Audit and implementation | We do the work. Rendering, redirects, canonicals, structured data, performance, architecture and internal linking, tested on staging and deployed with your approval. |
| Alongside your own team | We scope the work, write the tickets in a form your in-house or agency developers can pick up, and review the implementation. |
What is the difference between a technical SEO agency, consultant and specialist?
An agency or company audits and also changes the site, a consultant audits, prioritises and specifies while your developers implement, and “specialist” is a title that should mean depth in crawling, rendering and performance. The right choice depends on who will do the fixing, not on which word sounds most senior.
| Role | What they usually do | Choose it when |
|---|---|---|
| Technical SEO agency or company | Audits, then implements, with developers who can change templates, redirects and rendering. May also run the wider search programme. | You want the fixes made, or the platform is complex enough that someone has to write code. |
| Technical SEO consultant | Audits, prioritises, writes specifications and reviews what ships. An SEO consultant sells judgement rather than hours of implementation. | You have capable developers and need to know exactly what to ask them to do, and in what order. |
| Technical SEO specialist | Often a job title rather than a distinction. Ask what the specialism has produced: a rendering fix, a migration, a clean-up of a catalogue. | You have one narrow, difficult problem, such as a faceted navigation that generates endless URLs. |
| General SEO with technical hygiene | Covers titles, content and links, and checks the basics without going deep on crawling or rendering. | The site is simple, runs on a standard CMS, and the real gaps are content and authority. |
Why is technical SEO different for software and SaaS companies?
Because the fixes usually require changing the application rather than the content — which is exactly where a conventional SEO agency stops and hands you a document. It is a niche nobody local serves, and one we are unusually placed for.
Software and SaaS websites break the normal rules. They are usually single-page applications, often behind authentication, frequently with documentation on a separate subdomain, and typically with a marketing site and a product that share a domain but nothing else. Standard SEO advice does not survive contact with them, and neither does a standard CMS — which is usually why they were built as web applications in the first place.
We can go further, because we build applications: the same team handles bespoke software builds and multi-tenant SaaS platforms, so a rendering change or a routing change is a normal piece of work rather than a request to a third party. If that is your situation, tell us what the stack is and we will say whether it is worth auditing at all.
The point
If that is your situation, tell us what the stack is and we will say whether it is worth auditing at all.
How do you judge a technical SEO company, consultant or specialist?
Judge them on whether they show evidence, explain priorities in plain English, say what they would leave alone, and either change the site or specify the change precisely. A confident answer to a hard question about rendering tells you more than a long list of tools.
- Ask to see one finding with its proof. A good answer shows the affected URL, what a crawler received, why that matters and what fixing it involves. A finding with no evidence is an opinion.
- Ask what they check first. A good answer starts with whether pages can be indexed and whether the content exists in the HTML response, because nothing after that matters if they cannot. Vitals scores come later.
- Ask what they would ignore. A good answer names real noise: missing meta keywords, heading-order warnings, hundreds of near-identical low-severity flags. A supplier who treats everything as urgent has not prioritised.
- Ask who changes the site and how it is tested. A good answer is staging first, approval before deployment, and a re-test against the baseline. Compare it with the checks in what an SEO audit includes.
- Ask what they cannot see. A good answer admits limits, such as having no server logs or no access to a staging environment, and says how the findings are qualified as a result.
- Ask for access on your terms. A good answer works from read-only access to your Search Console and analytics, which are yours throughout, and does not need a login into anything it will not touch.
- Ask whether technical work is the right first step. A good answer will sometimes say no, and explain what would come first instead.
What drives the cost of technical SEO?
Site size is the first thing we ask about, because crawling a few dozen URLs and crawling a catalogue that generates them at template level are different pieces of work. After that it is platform complexity, whether content is rendered client-side, whether server logs exist, whether a migration is involved, and who does the implementing.
- How many URLs there are. A small server-rendered site is a crawl and a careful read. A large catalogue repeats its problems at template level, so the diagnosis and the checking of every fix scale with it.
- How complex the platform is. A standard CMS behaving in known ways is quicker to assess than a bespoke application, a headless build, or a stack whose behaviour nobody has documented. Where the stack is the problem rather than its settings, the real question becomes whether the platform itself is the constraint.
- Whether content is rendered client-side. A rendering problem moves the fix out of the content and into the application, which makes implementation a development job rather than an editing one.
- Whether server logs are available. Where they are, log analysis shows what search engines genuinely crawl and how much budget goes to pages that do not matter. Where they are not, we work from crawl and Search Console data instead.
- Whether a migration is involved. Mapping every existing URL and planning redirects before anything moves is more work than auditing a stable site, and cheap compared with losing the pages that earn your traffic. It is planned alongside the rebuild or replatform itself rather than after it.
- Who does the fixing. We can implement on staging and deploy with your approval, or scope the work, write tickets your own developers can act on, and review what ships.
- Whether it is a one-off or continuous. The structural fixes happen once. The monitoring afterwards — new content creating new problems, updates breaking structured data, performance drifting — sits inside an ongoing search engagement or a website care plan, both of which are covered in what SEO costs per month in the UK.
When is technical SEO the wrong first step?
Technical SEO is the wrong first step when the site is small, server-rendered and already easy to crawl, when almost nobody searches for what you sell, or when the real gap is content or the offer itself. In those cases the work costs more than it returns, and an honest supplier says so before starting.
A clean, standard site often needs a light check rather than a project, and the effort belongs elsewhere: pages that answer the questions buyers ask, or, for a business with a physical location, local search work on the profile and listings. Spending on crawl budgets for a thirty-page brochure site is a way of feeling busy.
The opposite mistake is leaving it too late. If a redesign or a platform change is planned, technical work comes first, not after launch, because moving a site without losing its rankings is far cheaper to plan than to repair. And if you need enquiries before any of this can pay back, comparing SEO with paid search is the better place to begin.
The point
If a redesign or a platform change is planned, technical work comes first, not after launch, because moving a site without losing its rankings is far cheaper to plan than to repair.
What Technical SEO covers
Not a menu to pick from. Most projects use some of this and ignore the rest, and the scope conversation is mostly about working out which half you actually need.
Crawlability
Robots directives, crawl budget, orphaned pages, crawl traps and faceted navigation generating infinite URLs.
Indexation and canonicals
What is indexed against what should be, canonical targets, parameters, pagination, protocol and trailing-slash resolution.
JavaScript rendering
Checking what a non-rendering crawler actually receives, and moving content into the HTML response where it is missing.
Site architecture and internal linking
Click depth, how link equity flows, and whether thin pages are competing instead of one strong page owning the term.
Core Web Vitals and performance
LCP, INP and CLS, image handling, render-blocking resources, fonts, caching and third-party scripts, measured on real mobile conditions.
Mobile and accessibility
Responsive behaviour, tap targets, viewport configuration, semantic structure, contrast and keyboard navigation.
Structured data
What exists, whether it validates, whether it matches the visible page, and what is missing.
Redirects and migration safety
Chains and loops, 404s that used to earn links, and a full URL map before anything moves.
International and hreflang
Consistent, reciprocal signals across countries and languages. Wrong hreflang is worse than none.
Log file analysis
Where the data exists, what search engines are really crawling, how often, and how much budget goes to pages that do not matter.
Why this is worth doing properly
The audit is not the point
A technical audit is easy to produce and easy to ignore. We are the developer, so a finding becomes a ticket in the same team's backlog rather than an email to somebody else's.
Findings ranked by impact, not by tool severity
High, medium and low, with what each issue costs you and what fixing it involves — instead of 300 undifferentiated warnings exported from a crawler.
Specifications a developer can act on
Each fix comes with a technical specification written for an engineer rather than a marketer, so your team can pick it up without a translation layer.
Rendering problems actually get found
JavaScript rendering is the one most audits miss entirely, and it is the deepest hole a modern site can be in. We check it first.
Migrations without permanent loss
Every existing URL mapped, 301s planned for the pages that earn traffic and links, and monitoring for the weeks after launch.
What you are handed, and who this suits
Deliverables
- A prioritised findings report — high, medium and low impact, with what each issue costs you and what fixing it involves
- A technical specification for each fix, written for a developer rather than a marketer
- Crawl data, Core Web Vitals measurements and indexation status as a baseline
- A structured data plan with the actual JSON-LD
- A redirect map where one is needed
- A working session to walk through it
- Re-testing after implementation, so you can see what changed
Everything on that list is yours on final payment, in your own company's accounts — the handover is written into the contract, not offered as a favour at the end.
Usually a fit for
- Sites built on a modern JavaScript framework, where content may never reach the HTML response
- Large sites and e-commerce catalogues generating duplicate titles and infinite URLs at template level
- Businesses planning a redesign, replatform or domain migration
- Anyone holding an audit from another agency that has never been implemented
- Software and SaaS companies whose marketing site and product share a domain but nothing else
- Sites that rank acceptably in Google but are invisible to AI crawlers and social preview bots
Built with
- Google Search Console
- Core Web Vitals (LCP, INP, CLS)
- JSON-LD structured data
- Server-side rendering
- Log file analysis
- 301 redirect mapping
- Robots.txt and XML sitemaps
- hreflang
Chosen per project, not per fashion. If your team already runs something else and can maintain it, that usually wins.
Ask what this would involve for youFour gates, and you sign off at each one
Every stage ends with something you can read and approve — access and baseline, crawl and render check, prioritised findings, working session. Nothing moves to the next stage until you say so.
- 01
Access and baseline
Search Console, analytics and, where available, server logs. We record crawl data, Core Web Vitals and indexation status as a baseline so the effect of the work is measurable later.
- 02
Crawl and render check
A full crawl, plus a non-rendering fetch of key templates to see exactly what a crawler that does not execute JavaScript receives.
- 03
Prioritised findings
High, medium and low impact, with what each issue costs you and what fixing it involves, plus a technical specification per fix.
- 04
Working session
We walk your team through the report, agree what matters and in what order, and answer the questions a PDF cannot.
Frequently Asked Questions
What is technical SEO and does my business actually need it?
Technical SEO is everything that determines whether a search engine can find, read, understand and rank your pages, as distinct from what is written on them. Every site needs it done once, properly; not every site needs it done continuously. Large sites, JavaScript frameworks and anything that has been migrated are where the problems usually are.
How do I know if my site has a JavaScript rendering problem?
View source on any page and search for a sentence you can see on screen. If it is not there, JavaScript is drawing it. That does not mean disaster — Google may render it fine — but it does mean somebody should check what is actually being indexed, and that AI crawlers and preview bots are likely seeing nothing.
Do you fix the issues or just report them?
Both are available and most clients want the fixes. We build websites and software, so implementation is our normal work rather than a stretch. If you have your own development team we will write the specifications for them and review the result.
How long does a technical audit take?
It depends on how many URLs there are, how complex the platform is, and whether server logs are available. A small server-rendered site is a crawl and a careful read; a large catalogue repeats its problems at template level. Implementation length is decided by the findings, so we scope it once they exist.
What does a technical SEO audit cost?
It is driven mainly by how many URLs the site has and how complex the platform is: a small server-rendered site and a templated catalogue are different pieces of work. Implementation is scoped separately once the findings exist, and whether we make the fixes or only specify them changes the shape of it. We scope it on a call.
Will you work with our existing development team?
Yes, and it often works well. We scope the work, write tickets your developers can act on without a translation layer, and review what ships. Developers generally prefer this to receiving a marketing PDF, because it is written in their language.
Can you help with a site migration without losing rankings?
Yes, and this is where the most damage gets done in our industry. Before anything moves we map every existing URL, identify which pages earn traffic and links, plan 301 redirects for all of them, and set up monitoring for the weeks after launch. What causes permanent loss is launching without a redirect map, and it happens constantly.
Is technical SEO a one-off or ongoing?
Mostly one-off, with maintenance. The big structural fixes happen once. After that it is monitoring — new content creating new problems, plugin updates breaking structured data, performance drifting as the site grows. That maintenance sits naturally inside a retainer or an ongoing care plan for the site.
What should I look for in a technical SEO company?
Look for evidence over vocabulary: a sample finding with its proof, a priority order that leaves the noise out, a named person who will change the site, and a re-test against a baseline afterwards. Be wary of a long tool-generated report with nothing ranked, and of anyone who cannot explain rendering in plain English.
Do Core Web Vitals affect rankings?
Yes, but modestly. They are part of Google's page experience signals, so they tend to matter when pages are otherwise close in relevance, and they matter to visitors regardless. Poor scores on a phone are usually a conversion problem before a ranking one. Core Web Vitals explained covers each measure.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.