Technical SEO

What technical SEO actually covers

Technical SEO is everything that decides whether a search engine can reach, render, understand and store a page. It comes before content and links because none of those matter for a page Google never indexes. In practice it is a short list done thoroughly.

• Crawlability: robots.txt, XML sitemaps, internal linking, crawl traps, orphan pages, and whether the server stays up when a crawler requests thousands of URLs in an hour.
• Indexability: canonicals, noindex, duplicate and thin pages, parameter handling, pagination, and what Search Console reports as "Crawled, currently not indexed".
• Rendering: whether content that depends on JavaScript is visible to Googlebot and to AI crawlers, most of which do not run scripts at all.
• Status codes: 404s, redirect chains, soft 404s and server errors under crawl load.
• Speed: Core Web Vitals on field data from real Chrome users, especially LCP and INP on mobile.
• Structured data: valid markup that matches what is on the page.
• Site-level files: robots.txt rules for search and AI crawlers, sitemap accuracy and lastmod dates, hreflang where there is more than one language or country.

Technical SEO audit services: what the full audit includes

The full audit is the first thing we do on every plan, and it is also available on its own for CAD $1,800, credited against month one if you start a plan within 60 days. It runs in this order.

1. Full crawl. We crawl every URL the way a search engine does, following links, sitemaps and redirects, and record status, canonical, title, headings, word count, internal links in and out, and render differences between raw and rendered HTML.
2. Index comparison. The crawl is compared with Search Console's index coverage report and with URL inspection on the pages that matter most, so we know what Google has, what it has dropped, and why.
3. Log sample. Where you can export server logs, we read what Googlebot and the AI crawlers actually requested, how often, and what response they received. Logs show crawl waste that no crawler can.
4. Speed on field data. Core Web Vitals from the Chrome UX Report, per template, with the specific element or script responsible when a metric fails.
5. Site-level checks. robots.txt, sitemap, llms.txt, hreflang, HTTPS and redirect behaviour across www, trailing slashes and parameters.
6. Prioritised fix list. Every issue with how many pages it affects, what it likely costs in visibility, who fixes it (us or your developer) and how the fix will be verified.

Our free page-level audit runs a subset of these checks on a single URL in about 20 seconds. It is a useful first look, not a replacement for a crawl of the whole site.

The problems we find most often

In roughly this order of frequency:

1. Internal links to pages that were removed or never built, which waste crawl budget and show up as 404s in Search Console.
2. Pages in the sitemap that are noindexed, redirected or canonicalised elsewhere, so the sitemap tells Google one thing and the page another.
3. Client-rendered content that replaces the server HTML on load, which delays the largest paint, shifts the layout, and is invisible to crawlers that do not run JavaScript.
4. Orphan pages that exist in a sitemap but have no internal link pointing to them.
5. A server or CDN that returns 5xx or 429 under a burst of requests, which is exactly what a crawl is.
6. Titles and descriptions truncated or duplicated across templates.
7. A CDN or firewall rule that blocks OAI-SearchBot, PerplexityBot or ClaudeBot by default, which removes the site from AI answers without anyone deciding to do that.

None of these are exotic. They are common because nobody checks them after launch, and every deploy can reintroduce them.

What we need from you

• Read-only Search Console access for every property (www and non-www, http and https, and any subdomains).
• A way to ship changes: either CMS and code access for us, or a developer on your side who will take tested tickets. We write tickets with the exact file, line or setting where we can.
• Server logs if your host can export them. Not required, but the audit is better with them.
• A staging environment for template-level changes on larger sites.
• Honesty about history: past migrations, penalties, paid links and previous agencies, so we are not surprised.

What technical SEO can and cannot do

It can get pages indexed that were not, stop signals being split across duplicate URLs, make templates fast enough to pass Core Web Vitals, and make sure AI crawlers can read the site. When a site has a real indexing or rendering problem, fixing it is often the single largest gain available.

It cannot make a thin page rank, replace missing content or authority, or guarantee a position. A site that is technically perfect and has nothing worth ranking stays where it is. That is why technical work is paired with on-page SEO and content strategy on every plan. We will tell you when the technical audit is clean and the lever is elsewhere.

How the work is measured

• Index coverage: valid indexed pages versus excluded, and the reasons, from Search Console.
• Crawl stats: requests per day, response time and error share from Search Console's crawl stats report and from logs where available.
• Core Web Vitals: the share of URLs passing LCP, INP and CLS on field data, per template.
• Errors over time: 404s, redirect chains and server errors found on each scheduled recrawl.
• Clicks and impressions on the pages that were fixed, compared with the period before the fix. Technical fixes show up here last, usually one to three months after Google recrawls.

Each fix is listed in the monthly report with the date it shipped and what changed afterwards. See the sample report for the format.

Common failure modes

Technical SEO fails in predictable ways. We check for each of these on a schedule.

• The fix is reverted by a deploy. A template change is overwritten by a theme update or a rebuild from an older branch. Scheduled recrawls catch it.
• Staging settings reach production. A noindex tag or a robots.txt disallow written for staging goes live with the release.
• A plugin adds a second canonical or a second title. Two tags, two answers, Google picks one.
• A migration ships without a redirect map. Old URLs 404 and years of links point at nothing. Our migration protection add-on exists for exactly this.
• Speed fixes chase a lab score. A Lighthouse number improves and the field data does not, because the real problem was a third-party script loading for logged-in users.
• Bots blocked by accident. A CDN bot-protection setting starts challenging Googlebot or AI crawlers after a settings change nobody thought was related to search.

What we will not do

We will not sell you a score. A Lighthouse number is a lab measurement; Google ranks on field data and on whether the page answers the query. We will tell you when a technical issue is cosmetic and not worth your developers' time, and we will not invent urgent problems to justify the retainer.

Deliverables

How it runs

1. Crawl and inspectWe crawl the site and inspect URLs in Search Console to find what is not indexed and why.
2. PrioritiseIssues are ranked by pages affected and likely traffic impact, not by how alarming they sound.
3. FixWe implement directly or brief your developers with exact changes.
4. VerifyEvery fix is confirmed in the tools that found it, then watched on scheduled recrawls.

Which plan includes it

Compare all plans →

Questions

Related