The Complete Guide to Technical SEO

Great content on a technically broken website rarely ranks. Technical SEO is the plumbing behind your visibility — invisible when it works, catastrophic when it doesn't. A site can have brilliant copy, a strong backlink profile, and a beautiful design, and still sit invisible on page five if Googlebot can't crawl it cleanly, can't tell what a page is about, or renders it differently than a visitor does. This is the complete foundation, broken into the areas that matter most, with the specific things we check on every technical audit.

Most technical SEO problems aren't dramatic — nobody notices a slowly growing crawl budget waste, a canonical tag pointed one character off, or a schema block that quietly stopped validating six months ago. They accumulate instead, each one shaving a little more visibility off a site until the gap between "should be ranking" and "is ranking" becomes too large to ignore. That's what makes a structured, section-by-section audit worth doing properly rather than skimming for the obvious issues.

1. Crawlability

Before Google can rank a page, it has to be able to find and crawl it. A clean robots.txt file, a complete and accurate XML sitemap, and a logical internal linking structure all make sure Googlebot can discover every important page on your site — and that it doesn't waste time crawling pages that don't matter.

Crawl budget is finite, especially on larger sites: Google allocates a rough ceiling on how many URLs it will fetch from your domain in a given window, based on your site's authority and server response health. Every faceted filter URL, session parameter, or internal search results page that gets crawled is budget not spent on the pages you actually want ranked. A well-configured robots.txt should explicitly disallow low-value URL patterns (like ?sort= or ?filter= parameters), and your XML sitemap should contain only canonical, indexable URLs — not a dump of every URL the CMS happens to generate. We also check for orphan pages: pages that exist and may even rank, but have zero internal links pointing to them, making them nearly invisible to both users and future crawls.

2. Indexation

Being crawled doesn't guarantee being indexed. Duplicate content, thin pages, and misconfigured canonical tags can quietly keep valuable pages out of Google's index entirely. Regularly auditing your indexed page count against your actual site structure catches these issues before they cost you traffic.

The single most common indexation bug we find on new sites is a canonical tag pointing at the wrong URL — sometimes a staging domain, sometimes a competitor's live site, sometimes just a trailing-slash mismatch between the canonical and the actual served URL. Google treats the canonical tag as a strong signal of "this is the real page," so if it points anywhere other than the page itself, you're actively telling Google not to index the page you want ranked. Google Search Console's Coverage report is the definitive source of truth here: it tells you exactly which URLs are indexed, which are excluded, and why — "Duplicate without user-selected canonical," "Crawled – currently not indexed," and "Discovered – currently not indexed" are the three statuses worth watching most closely, since each points to a different underlying problem (content quality, crawl priority, or technical misconfiguration, respectively).

3. Site Architecture

A flat, logical structure — where every important page is reachable within three clicks of the homepage — distributes ranking authority efficiently across your site. Deep, buried pages rarely rank well, no matter how good the content on them is.

The most scalable version of this is a pillar-and-cluster model: a broad hub page (like a services page or a market page) links out to focused supporting articles, and each of those articles links back to the hub and sideways to related articles. This concentrates topical authority instead of scattering it across disconnected pages competing with each other for the same keywords. URL structure should mirror this hierarchy in plain, descriptive slugs — /services/local-seo reads clearly to both users and Google, where a parameter-heavy or ID-based URL communicates nothing. Breadcrumb navigation, paired with BreadcrumbList schema, reinforces this hierarchy explicitly and is a small, easy structural signal that consistently pays off in how Google understands site sections.

4. Schema Markup

Structured data tells Google explicitly what your content is — a business, a review, an article, a product, an FAQ — rather than making it infer this from raw text. Implementing Organization, LocalBusiness, Article, and FAQ schema correctly increases your eligibility for rich results that stand out in search.

JSON-LD is the format Google recommends over microdata or RDFa, since it lives in a single script block rather than being woven through your HTML, which makes it far easier to keep accurate as a page changes. The schema types worth prioritizing depend on the page: service and location pages benefit from LocalBusiness and Service schema with accurate areaServed values, blog content benefits from Article and FAQPage, and any page with a clear step-by-step process is a candidate for HowTo. The most common schema mistake isn't a missing tag, it's a contradictory one — schema that states one address, service area, or business name while the visible page says something else. Google's structured data guidelines are explicit that markup must reflect visible page content; mismatches don't just fail to help, they actively risk a manual action. Google's Rich Results Test is worth running after every schema change, not just once at launch.

5. Mobile-First Indexing

Google predominantly uses the mobile version of your site for indexing and ranking, regardless of desktop traffic share. Any content, links, or structured data missing from your mobile experience is effectively invisible to Google's ranking systems.

This catches more sites than people expect, particularly ones that hide secondary content behind accordions or tabs on mobile to save space, or that serve a stripped-down mobile navigation missing links present on desktop. Both practices are fine for user experience, but only if the underlying content and links are still present in the page's HTML — collapsed, not deleted. Tap target sizing and viewport configuration also factor into mobile usability signals: buttons and links need enough spacing to be tappable without misfires, and a missing or misconfigured viewport meta tag can cause Google to flag a page as not mobile-friendly even when it renders visually fine on a desktop-sized emulator.

6. Core Web Vitals

Loading speed, interactivity, and visual stability are measured directly and factored into rankings, through three specific metrics. Largest Contentful Paint (LCP) measures how long the biggest visible element takes to load, and should land under 2.5 seconds. Interaction to Next Paint (INP) measures how responsive the page feels to clicks and taps, and should stay under 200 milliseconds. Cumulative Layout Shift (CLS) measures how much visible content jumps around as a page loads — images without reserved dimensions and late-loading ads or banners are the usual culprits, and it should stay under 0.1. See our companion guide on website speed for the specific fixes that move these metrics fastest.

7. JavaScript Rendering

Googlebot can execute JavaScript, but it does so in a separate rendering pass after the initial crawl, and that pass has its own resource limits and queue delays. Content that only appears after client-side JavaScript runs — common in single-page apps built without server-side rendering — can take significantly longer to be indexed than static HTML, and in some cases doesn't get indexed at all if the render fails or times out. Server-side rendering, static generation, or at minimum ensuring critical content (headlines, body copy, primary links) is present in the initial HTML response rather than injected afterward, removes this risk entirely. Google Search Console's URL Inspection tool shows you the actual rendered HTML Googlebot sees, which is the fastest way to confirm nothing critical is missing.

8. Redirects and URL Hygiene

Redirects are a normal part of running a website, but they compound quietly. A redirect chain — URL A redirecting to B, which redirects to C — adds latency to every hop and dilutes the ranking signals passed along the way; Google generally recommends collapsing chains down to a single hop wherever possible. 301 redirects should be used for permanent moves, since they pass ranking signal to the destination, while 302s signal a temporary move and are treated more cautiously. Inconsistent trailing slashes, mixed http/https internal links, and unnecessary URL parameters all create duplicate paths to the same content, which is exactly the kind of ambiguity a canonical tag is meant to resolve — but resolving it at the source, with clean internal links, is more reliable than depending on canonicalization to clean up after the fact.

9. Multi-Region Technical SEO

For a business serving multiple distinct regions within the UK — different cities or service areas with genuinely different competitors and search behaviour — technical SEO has an extra layer: making sure Google understands which page is meant for which area. Consistent internal linking between location pages, accurate local schema (areaServed set precisely for each page, not just inherited from a global default), and genuinely distinct content per location all reinforce the same signal, so Google treats each page as a deliberate, relevant alternate rather than duplicate content competing against itself.

10. HTTPS and Security

HTTPS has been a baseline ranking requirement for years, and browsers now actively warn visitors away from non-secure sites with a visible "Not Secure" label in the address bar — a trust signal users notice even if they can't articulate why. Beyond the certificate itself, watch for mixed content warnings, where a secure page still loads an image, script, or stylesheet over plain HTTP; browsers block or flag these resources, which can silently break page functionality. HSTS (HTTP Strict Transport Security) headers reinforce this further by telling browsers to never attempt an insecure connection to your domain at all, closing off a class of downgrade attacks entirely. If your site isn't fully secured end to end, it's actively costing you both user trust and rankings.

11. Monitoring and Ongoing Audits

Technical SEO isn't a one-time project — a site that passes every check at launch can regress within weeks as new pages, plugins, or a redesign get shipped without SEO review. A CMS update can silently reintroduce noindex tags on a template, a new marketing campaign can spin up thousands of low-value parameter URLs, or a developer can accidentally block an entire section in robots.txt while testing something unrelated. The practical fix is a standing cadence, not a one-off audit: a monthly check of Search Console's Coverage and Core Web Vitals reports to catch indexation or speed regressions early, a quarterly full crawl to catch broken links, redirect chains, and orphan pages before they compound, and a mandatory technical review step built into any launch checklist for new pages or templates. Treated this way, technical SEO stops being a periodic emergency and becomes a maintained asset, the same way you'd monitor uptime or security patches.

None of these eleven areas work in isolation — a technically flawless site with thin content won't outrank a well-optimized competitor, and world-class content on a site Google can't crawl or trust never gets the chance to compete at all. The point of a technical audit isn't to chase a perfect score on every metric; it's to remove the artificial ceilings that stop your actual content and authority from being reflected in your rankings.