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.
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
On this page
- 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 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?
- Should you buy the audit, the implementation, or both?
- Why is technical SEO different for software and SaaS companies?
- What drives the cost of technical SEO?
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 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.
The point
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.
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.
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. |
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.
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.
How We Work
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.
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.
Prioritised findings
High, medium and low impact, with what each issue costs you and what fixing it involves, plus a technical specification per fix.
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 there are and how complex the platform is — a small server-rendered site and a templated catalogue are not the same piece of work. Implementation is scoped separately, once the findings exist. If you go on to a retainer we credit the audit fee against the first month.
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.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.