Technical SEO
Technical SEO audit and implementation
Find what stops your pages being discovered, rendered and indexed, fix it in your CMS or codebase, and verify the fix after it ships — with every finding labelled as measured or hypothesis.
The situation
A page Google cannot reach, render or trust cannot rank
Technical SEO is the unglamorous layer underneath everything else: can search engines find your pages, do they see the same content your visitors see, do your signals agree about which URL is the real one, and do your redirects, sitemaps and status codes tell a consistent story? When any of that is wrong, content and authority work is wasted on pages that never make it into the index — or the wrong versions do.
Most technical audits produce a hundred-line spreadsheet of "errors" with no sense of which ones matter. Ours separates what was measured from what is suspected, ranks findings by the pages they affect, and ends with a verified deployment rather than a list. We build websites, so we also implement the fixes ourselves when you want us to.
What you get
What technical SEO includes
Scoped from a crawl of your site and a rendered comparison of representative templates. The checklist we work from is published as the technical SEO audit checklist, so you can see exactly what gets checked.
Crawl and indexability audit
A first-party crawl of the site with the internal-link graph: robots directives, noindex, canonicals, redirects and redirect chains, sitemaps, status codes, orphan pages and click depth — each finding listed with the URLs it affects.
Rendering comparison
Raw HTML compared with the rendered page for representative templates, so JavaScript-dependent content, links and directives that search engines may not see are identified rather than assumed.
Findings ranked by evidence
Each finding labelled measured, partially measured or hypothesis, with the test that would confirm it and the pages at stake, so remediation starts with what is known to be broken.
Implementation
Fixes shipped by us in your CMS or repository, or specified precisely for your developer — including template changes, redirect maps, sitemap generation and structured data.
Post-deployment verification
Every fix re-crawled and checked against Search Console after it ships, with the before and after recorded. A fix is not closed until it is verified live.
Migration and redesign safety
URL inventories, redirect mapping and staged verification when a site changes platform, structure or domain, so existing visibility is preserved rather than rediscovered later.
How it runs
Audit, fix, verify
Technical work is only finished when the live site behaves as intended and the change can be seen in search-engine data.
- 01
Crawl and baseline
Crawl the site, record indexing and coverage in Search Console, and capture representative rendered pages as the baseline.
- 02
Diagnose with evidence
Classify each finding as measured or hypothesis, attach affected URLs and the confirming test, and prioritise by pages at stake.
- 03
Implement
Ship fixes in your CMS or repository, or hand your developer a specification precise enough to deploy without questions.
- 04
Verify after deployment
Re-crawl, re-render and check Search Console to confirm each fix took effect; record before and after.
- 05
Monitor
Re-test representative templates after releases, and watch indexing and coverage for regressions.
What we need from you
Access to see the site the way crawlers do
Technical findings have to be verified against the live site and against Google's own data, which needs a few doors opened.
- Search Console access for the property, or permission to verify it.
- Crawl access without rate-limiting or bot blocking for our crawler, and a staging environment if one exists.
- CMS, hosting or repository access — or a developer who can deploy from our specification.
- An honest account of how the site is built and deployed, including any platform limits.
- For migrations: the old and new URL inventories and the launch timeline.
Measurement and reporting
Findings are measured, hypotheses are labelled
Crawlers and search engines can disagree, and lab tools do not see real users. We keep each source of evidence in its own lane and say which one supports each finding.
- First-party crawl data: status codes, directives, canonicals, links and depth, with dates.
- Rendered-versus-raw comparisons for representative templates.
- Search Console indexing, coverage and enhancement reports as the reference for what Google actually did.
- Lab performance runs kept separate from field Core Web Vitals, which reflect real users.
- A change log with implementation dates, so any movement can be related to a specific deployment.
What stays yours
Your code, your data, your record
- Implementation
- Changes are made in your CMS or repository under your control; nothing is hosted by us unless you ask for hosting.
- Audit and verification record
- Findings, affected URLs, tests, deployment dates and before-and-after evidence are documented and yours to keep.
- Search Console
- Verified under your account; we work with delegated access.
- Migration maps
- Redirect maps and URL inventories are delivered as files you can reuse with any provider.
Questions
Asked about technical seo
Straight answers to what people ask before they commit. Anything else, message us.
Our site is on WordPress, Shopify or a page builder. Can you still fix it?
Usually, within the platform's limits. Some fixes are configuration, some need theme or template changes, and a few are impossible on a given platform. The audit says which is which for your site, and what a platform limit means for the pages affected.
How is this different from running a free site audit tool?
Tools list every deviation from a generic rule with equal weight. We crawl the site, compare rendered pages with raw HTML, check Google's own indexing data, and then rank findings by the pages they affect and label how well each was measured. The output is a plan and a verified deployment, not a spreadsheet.
We are redesigning our website. When should technical SEO start?
Before the new site is built, not after launch. A URL inventory and redirect map prepared in advance, and a staged verification before the switch, preserve the visibility you already have. Fixing a migration afterwards is slower and rarely complete.
Do you also fix page speed and Core Web Vitals?
Yes, where performance is a technical constraint rather than a design choice. We keep lab measurements and field Core Web Vitals separate, diagnose by template, and ship fixes we can verify — while being clear that faster pages are a quality improvement, not a guaranteed ranking change.
Related services
- SEO programmes →
When technical fixes are one part of a wider plan for content and authority.
- Local SEO and Google Maps visibility →
For businesses whose visibility depends on location and Business Profile foundations.
Read how we think
- Technical SEO Audit Checklist →
The evidence-led checklist we audit against — use it on your own site first.
- Robots, Noindex and Canonical Controls →
Which control affects crawling, which affects indexing, and what happens when they conflict.
- Core Web Vitals and page experience guide →
Field data versus lab data, and how to investigate a poor metric.
Tell us about your website and what it needs to do
We start with what can be measured, say plainly what cannot be promised, and quote only after we have looked.