Technical SEO is the work that lets Google crawl, render and index your site without obstacles. The rule behind it is simple: if Google can't read a page, how good the content is doesn't matter — that page effectively doesn't exist in Search.
- It rests on three questions: can Google crawl the site, render it, and index it?
- Scope: indexing, speed and Core Web Vitals, the mobile version, status codes and redirects, canonicals, JavaScript rendering, structured data.
- Results often arrive quickly — the effect of technical fixes usually shows up in Search Console within days or weeks.
- Technical SEO alone doesn't win rankings; it's the precondition that lets everything else work.
What technical SEO is
Google Search runs in three stages: crawling, indexing and serving. Technical SEO owns the first two. Content and authority work matter at the third stage — but a page that fails the first two never gets there.
On JavaScript-driven sites another stage appears in between. Google's documentation lists it as: "1. Crawling 2. Rendering 3. Indexing" — the bot downloads the file, executes it like a browser, then indexes it. If rendering fails, the content exists but Google never sees it.
You can check all three on your own site with a free tool — Search Console. We explain how to read it here: what Google Search Console is. For the wider picture: what SEO is and how it works.
When it's the priority
Technical SEO isn't always first in the queue. If any of the symptoms below apply, it should be.
| Symptom | Likely technical cause |
|---|---|
| Pages don't appear in Google at all | robots.txt block, noindex tag, canonical error, sitemap problem |
| Lots of "Discovered — currently not indexed" in Search Console | Crawl budget, volume of low-value pages, weak internal linking |
| Mobile traffic lags far behind desktop | Missing content on the mobile version, mobile rendering problems |
| The site was migrated or redesigned and traffic dropped | Broken redirect chains, changed URLs, lost canonical signals |
| Pages load visibly slowly | Core Web Vitals — LCP, INP and CLS problems |
| Products or services never show in rich results | Structured data is missing or invalid |
The opposite also holds: for a small, fast site that indexes cleanly, the technical work is short — and the budget is better spent on content.
What technical SEO includes
1. Crawling and indexing
robots.txt, sitemap.xml, indexing directives, internal link structure and crawl budget. The most common trap here is combining noindex with a robots.txt block. Google's documentation is explicit: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler." Block the page in robots.txt and the bot never sees the noindex — so the page can stay in the index.
Crawl budget, meanwhile, isn't everyone's problem. Google sets the threshold in numbers: large sites with more than a million unique pages, and sites of 10,000+ pages whose content changes daily. Below that, it isn't worth the time. What the indexing statuses mean: the Search Console page indexing report.
2. Speed and Core Web Vitals
Google's user experience metrics consist of three numbers, with these "good" thresholds (for 75% of users):
| Metric | What it measures | "Good" threshold |
|---|---|---|
| LCP — Largest Contentful Paint | How fast the main content appears | 2.5 seconds or less |
| INP — Interaction to Next Paint | How fast the page responds to taps and clicks | 200 milliseconds or less |
| CLS — Cumulative Layout Shift | Visual stability — content jumping around | 0.1 or less |
Note: the older FID metric was retired in 2024 and replaced by INP — if you see an audit still reporting on FID, that audit is out of date. On ranking impact Google is precise: "Core Web Vitals are used by our ranking systems", but "There is no single signal" — speed alone is not a magic button, and relevance always comes first.
3. The mobile version (mobile-first indexing)
Google's definition: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." The practical consequence is that content absent from the mobile version doesn't exist as far as Google is concerned. The design can differ — accordions, tabs and collapsed sections are fine — but the text itself has to be there.
4. Status codes, redirects and canonicals
The server's response is a direct instruction to Google. Redirect chains, broken links, correct handling of removed pages and canonical signals for duplicate URLs all live here. Details: HTTP status codes and SEO, 301 vs 302, 404, 410 and soft 404.
5. JavaScript rendering
On SPAs and JS-heavy sites we check how the content actually reaches the bot. Google warns: "Google Search won't render JavaScript from blocked files or on blocked pages" — one JS or CSS file disallowed in robots.txt can make an entire page look empty. Server-side rendering or prerendering is recommended, because "not all bots can run JavaScript".
6. Structured data (schema markup)
Marking up products, services, articles, FAQs and organisation data in the format Google understands. Done correctly it opens the door to rich results and establishes your brand as an entity: schema markup and entity linking.
The technical SEO tools we use
In a technical SEO audit every claim is backed by a measurement. This is the toolset:
| Tool | What we use it for |
|---|---|
| Google Search Console | URL Inspection to see the page as Google does, indexing statuses, the Core Web Vitals report, sitemap management. |
| Screaming Frog SEO Spider | Full site crawls: redirect chains, broken links, duplicate titles and canonicals, crawl depth analysis. |
| PageSpeed Insights | LCP, INP and CLS with both lab data and real user (CrUX) measurements. |
| Lighthouse | Page-level performance, accessibility and best-practice audits; re-measurement after each fix. |
| Chrome DevTools | Render blockers, the network waterfall, JS errors — where we find the real cause of a speed problem. |
| Chrome UX Report (CrUX) | Field data from real users and comparison against competitors. |
| Rich Results Test | Checking whether structured data is actually read by Google. |
| Schema Markup Validator | General Schema.org syntax validity, including errors Google's own test doesn't flag. |
| Ahrefs Site Audit | Recurring automated crawls and how issues trend over time. |
| Semrush Site Audit | A technical health score and a second source for prioritisation. |
| web.dev — Core Web Vitals | The official source for thresholds and methodology; we hand it to dev teams as the reference. |
For quick first checks you can also use the free SEO tools on our site.
How the audit runs: five stages
- Full crawl (1–3 days). The site is crawled as a bot sees it: every URL, status code, canonical, title and internal link depth is extracted.
- Comparison with what Google sees. The crawl is matched against Search Console data — which pages are indexed, which aren't, and why. The gap is always the most valuable information.
- Performance measurement. LCP, INP and CLS are measured per template type (home, category, product, blog) and the root cause is isolated.
- A prioritised report. Every issue comes with three columns: impact, implementation effort, and the specific fix — written in language a developer can act on.
- Implementation and re-check. We apply the fixes ourselves or hand them to your team, then repeat the same measurements so the change is confirmed with numbers.
The mistakes we see most
These turn up in roughly every second technical SEO audit we run — you can use the list as a first self-check.
- A noindex left over from staging. The site goes live but the template still carries
noindex— pages stay out of the index for months. - CSS/JS blocked in robots.txt. Google sees an empty or broken page, because it won't render from blocked files.
- Pagination URLs canonicalising to themselves.
?page=2and?page=3end up competing with the main listing. - Redirect chains. A → B → C → D. Every hop loses signal and burns crawl budget.
- http/https and www/non-www duplicates. The same content exists at four different addresses.
- Missing content on mobile. Text present on desktop is absent from the mobile template — under mobile-first indexing that content doesn't exist.
- 404s and redirects inside the sitemap. Google is handed an inaccurate list, and trust in it drops.
- Unoptimised images. The single most common cause of LCP problems: huge files served without dimensions.
When results appear
The advantage of technical SEO is that results usually show up faster than with content. Once an indexing blocker is removed, pages can enter the index within days; speed fixes, being based on real user data, typically surface in the Core Web Vitals report as the 28-day measurement window fills.
There are still no guarantees. Google's own documentation states: "No one can guarantee a #1 ranking on Google." Technical work opens the possibility of visibility — content and authority are what fill it.
Technical work vs the monthly service
| Format | What it gives you | Who it suits |
|---|---|---|
| Technical SEO (this page) | A deep technical audit plus implementation, as a project | A business with technical problems or a new launch |
| SEO audit | Analysis and a prioritised task list only; you implement | A business with its own developers |
| SEO service | Technical work + content + authority + monthly measurement, continuous | Businesses making organic a primary sales channel |
In practice the order is: build the technical base first, then start the monthly work. Out of order, money spent on content leaks away through technical faults.
What the price depends on
The cost of a technical SEO project isn't fixed — the volume of work moves with these five factors:
- Number of URLs — crawling and analysing a 50-page site and a 50,000-product catalogue are not the same job.
- The platform — an off-the-shelf CMS, a custom system, or a JS framework (React, Vue, Next.js) each need a different approach.
- Who implements — whether we apply the fixes or hand them to your developer.
- Languages and regions — hreflang and multilingual canonicals are a separate body of work.
- Depth of the problem — a handful of fixes, or a structural rebuild.
Package scope: SEO pricing. For a calculation on your specific site: get a quote.
Frequently asked questions
Is technical SEO a one-time job?
The main body of work is a project and it ends. But a site is a living thing: new pages, new features and plugin updates all create technical debt. A control crawl once or twice a year is worth it.
If the site is fast, will rankings improve?
Not on its own. Google says Core Web Vitals are used by its ranking systems, but also that "There is no single signal", and relevance always outweighs it. Speed is what separates two otherwise equal results.
We have a developer — do we still need you?
Often this is the best model: we define what to change, why, and in what order, and your developer implements it. It's both faster and cheaper.
Do we need to rebuild the site?
Usually not. We only propose a rebuild when the platform itself is the obstacle, and that conclusion comes from the audit, backed by numbers.
I see a FID report — is that normal?
No. FID was removed from Core Web Vitals in 2024 and replaced by INP. A tool or vendor still reporting FID is working from an outdated methodology.
Traffic dropped after a migration — is it recoverable?
Usually yes. Most migration losses come from broken redirects, changed URL structures and lost canonical signals — all fixable. The sooner it's addressed, the smaller the loss.