Technical SEO that removes the reasons your pages cannot rank
Every page you want indexed is crawlable, renderable, fast enough, and described correctly, with the fixes shipped or specified so your developers can ship them.
For any company on JavaScript frameworks, headless CMSs, e-commerce platforms, or ageing WordPress builds where the content is fine but Search Console keeps reporting problems nobody on the team can explain.
Updated
What does a technical SEO service include?
Technical SEO covers the conditions a page has to meet before its content can rank: search engines must be able to discover it, fetch it, render it, index it, and understand which version is canonical. At Seorythm the service starts with a full crawl compared against your server logs and Search Console coverage data, which shows where discovery and indexing diverge. We then diagnose rendering (what Googlebot sees after JavaScript executes versus what is in the HTML), canonicalisation and duplication, redirect chains, internal link depth, XML sitemaps, robots directives, hreflang where relevant, Core Web Vitals against Google's thresholds (LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1), and structured data validity. Fixes are delivered either as pull requests on platforms we support or as tickets with acceptance criteria your developers can implement without SEO knowledge. Site migrations, replatforming, and domain changes are handled as a separate fixed-scope project with a pre-launch and post-launch checklist.
What you get
| Deliverable | Cadence | What it includes |
|---|---|---|
| Technical audit | Weeks 1 to 2 | Crawl, log file and Search Console comparison, rendering tests, Core Web Vitals field and lab data, structured data validation. Findings ranked by impact and effort. |
| Fix specifications | Sprint, continuous | Tickets with the problem, the evidence, the fix, and acceptance criteria. Written for developers who do not do SEO. |
| Fixes shipped by us | Where the platform allows | Pull requests on Astro, Next.js, WordPress, Webflow, and HubSpot builds. Reviewed by your team before merge. |
| Core Web Vitals work | As prioritised | LCP, INP, and CLS diagnosed per template with field data. Fixes to images, fonts, scripts, and layout stability. |
| Migration project | Fixed scope, separately priced | Baseline export, redirect map, staging tests, launch checklist, six-week monitoring. |
| Monitoring | Weekly during sprint, monthly on retainer | Crawl diff against the previous run, Search Console coverage changes, Core Web Vitals field data, and alerts for anything that regresses. |
How the work is done
Compare three sources before diagnosing
A crawl tells you what a crawler can reach. Server logs tell you what Googlebot actually fetched. Search Console, and its URL inspection tool in particular, tells you what Google indexed and what it did with the rest. Most technical problems live in the gaps between those three: pages the crawler finds but Googlebot never fetches (discovery problem), pages fetched but not indexed (quality or duplication problem), pages indexed under a different URL than intended (canonicalisation problem). We do not write the findings list until all three are in hand.
Templates, not pages
A site with ten thousand URLs usually has fewer than twenty templates. We diagnose and fix at template level, then confirm on a sample of pages. This is why the audit ranks findings by how many URLs they affect and how much traffic those URLs carry, rather than listing every instance a tool found. A single fix to a product template beats a hundred page-level edits.
Ship it or specify it
On platforms we support, we open pull requests against your repository and your team reviews them. On others, we write tickets a developer can implement without knowing anything about SEO: what is wrong, the evidence, the exact change, and how to verify it. We have found that the quality of the ticket determines whether a fix ships in a week or sits for a quarter, so we spend real time on them.
Migrations are a project, not a retainer item
Core Web Vitals are assessed against the thresholds Google publishes on web.dev, and INP, which replaced FID in March 2024, is the responsiveness metric we report. Rendering problems on JavaScript sites are diagnosed against Google’s own JavaScript SEO guidance, and duplicate URLs are resolved the way Google’s canonicalization documentation describes, not by canonical tags alone.
Replatforming, redesigns that change URLs, and domain changes are scoped and priced separately because the work is front-loaded and the risk is concentrated in one week. The site migration case study walks through one. If you are planning a migration, talk to us before the URL structure is decided, not after.
Technical work is the first stage of our SEO services programme because on-page SEO and links cannot compensate for a page that will not render. The technical SEO audit is where we find out what your site actually needs; the technical SEO audit checklist shows what it covers, and pricing shows what it costs.
What it costs
Fixed-price audit; sprint fee or project fee for migrations
The audit is $2,800 fixed for sites up to 1,000 URLs (from $4,800 above that). Ongoing technical work is part of the sprint fee, $4,800 to $7,400 a month. Migrations are quoted as a project based on URL count, platform, and whether the domain changes.
What moves the number
- Site size and template count
- Whether we ship fixes or specify them
- Platform (some are far slower to fix than others)
- Migration complexity (URL changes, domain change, CMS change)
Who this is not for
- Sites under a few hundred pages on a well-behaved platform with no Search Console warnings. You probably do not need this; the audit will tell you.
- Teams that cannot give us a technical contact or staging access. We cannot fix what we cannot see.
- Buyers who want a "technical SEO score" without the work. Scores from crawling tools are not the problem list.
- Proprietary platforms we cannot get code or template access to. We can still specify fixes; we cannot ship them.
Risks and how we manage them
| Risk | How we manage it |
|---|---|
| A fix breaks something else on the site. | Every change is made on staging first, reviewed by your team, and covered by a crawl diff after deployment. Redirect and canonical changes are logged so they can be reverted. |
| Core Web Vitals improve in the lab but not in the field. | We prioritise by field data (Chrome UX Report and your own RUM where available), and we report the field numbers, not Lighthouse alone. Lab scores are a diagnostic tool, not the target. |
| Recommendations are too vague for developers to act on. | Tickets include the exact URL, the evidence, the desired outcome, and acceptance criteria. If a developer cannot implement it from the ticket, that is our failure and we rewrite it. |
| Rendering problems go undetected because the crawl looked fine. | We compare raw HTML with rendered HTML for each template and check what is actually indexed with URL inspection, not only what a crawler reports. |
How do you handle a site migration without losing rankings?
A migration loses rankings when URLs change without a complete redirect map, when the new site renders content differently, or when internal links and canonicals still point at the old structure. Our process starts with a full crawl and export of the current site (URLs, titles, canonicals, internal links, structured data, and the ranking and traffic value of each URL). We build a one-to-one redirect map, test it against the staging site, and check that every high-value page renders the same primary content in the new build. Launch happens with the map in place, the sitemap updated, and Search Console change-of-address submitted where the domain changes. For the following six weeks we compare crawl stats, indexed page counts, and per-page rankings against the pre-launch baseline and fix regressions in order of traffic value. Some rankings dip for two to four weeks after a migration even when everything is correct; a drop that persists past that is a fault, and the baseline lets us find it.
Questions buyers ask
Which platforms do you work with?
We ship fixes on Astro, Next.js, WordPress, WooCommerce, Shopify themes, Webflow, and HubSpot. On other platforms we write specifications for your developers. Platform-specific limits are documented in the audit.
Do we need log file analysis?
For sites over roughly ten thousand URLs, or any site where Search Console shows large "crawled, currently not indexed" counts, yes. For small sites, Search Console and a crawl are usually enough, and we will say so rather than sell you the analysis.
Can you help with a JavaScript framework site?
Yes. Most of our technical work is on React, Next.js, or Vue sites where content depends on client-side rendering. The usual fixes are server rendering or static generation for indexable pages and removing the dependence on client fetches for primary content.
Do you report FID?
No. INP replaced FID as a Core Web Vital in 2024. We report LCP, INP, and CLS, using field data where available.
How much does technical SEO cost?
The technical SEO audit is $2,800 fixed for sites up to 1,000 URLs and from $4,800 above that. Ongoing fixes are part of the sprint at $4,800 to $7,400 a month, and a migration is quoted as a project. Those figures are 20% below what the large agencies publish for the same scope; the comparison is on the pricing page.
What if the audit finds nothing serious?
Then you have paid for confidence and a short list of small improvements, and we will recommend where the money is better spent, usually on-page or links. That happens, and it is the right outcome.
Start with the audit.
Two weeks, fixed price, and a prioritised list you can act on with or without us. If SEO is not the right channel for you, the audit will say so.