Technical SEO Services

How Google Decides What It Can Rank

Four things happen before a ranking exists, and they happen in order:

1. Crawl. Googlebot requests the URL. Blocked in robots.txt, unreachable through internal links, or sitting behind a slow server, and nothing after this point matters.
2. Render. The page is executed, JavaScript included, to see what a user would see. Rendering is queued and resource-limited, which is where JavaScript-heavy sites lose content that exists but never arrives in time.
3. Index. Google decides whether the result is worth storing. This is a judgment, not an automatic step, and it is where most skipped pages are skipped.
4. Rank. Only here do content, relevance and links come into play.

Every technical SEO problem is a break somewhere in the first three. It is also why «we rewrote the content and nothing happened» is such a common story — the content changed, but the page was never in the index to begin with.

Which is why our technical SEO services start with diagnosis rather than with a crawl. A tool will tell you a page has two H1 tags. It will not tell you that 40% of your crawl budget goes to filter URLs nobody should ever see, or that your product template ships an empty shell to anything that does not run JavaScript.

The Technical SEO Audit

A technical SEO audit is a full crawl plus server log analysis, checked against what Google actually did with your site. We run it in six groups:

• Crawl. Reachability, internal link depth, orphan pages, redirect chains, robots.txt rules, response codes and TTFB by template.
• Index. Sitemap URLs reconciled against what is genuinely indexed — not «the sitemap validates» but which of those URLs Google kept. Plus Google-selected canonicals, which disagree with the declared canonical more often than teams expect.
• Render. Raw HTML compared against the rendered DOM, template by template. Anything that appears only after hydration is a candidate for never being indexed.
• Speed. Field data first, lab data second, grouped by template rather than by URL — because that is how Search Console groups it and how fixes actually ship.
• Structured data. Validation, plus whether the markup matches what is visible on the page. That mismatch is what gets rich results removed.
• International. hreflang return tags, canonical conflicts between locales, duplicate locale paths in the sitemap.

What you get is an ordered backlog: each item with the traffic at stake, the effort to fix it, and enough detail for a developer to start without a follow-up call. Not 300 rows exported from a crawler.

Crawling, Indexing and Crawl Budget

Crawl budget is a real constraint only on large sites — roughly from tens of thousands of URLs, or anywhere URLs multiply on their own: faceted navigation, internal search pages, session parameters, calendars, endless pagination. On those sites the problem is almost never that Google crawls too little. It is that it crawls the wrong things.

Log analysis settles the argument. You can see which URL patterns Googlebot requests, how often, and what it received. The usual finding is uncomfortable: a large share of requests going to parameter URLs, expired filters and redirect chains, while the pages that make money get visited every few weeks.

Fixing «Crawled — currently not indexed»

Worth being blunt about this one, because half the industry sells a technical fix for it. In most cases it is not a technical fault. Google fetched the page, evaluated it, and chose not to store it. Google’s own Search Advocates have said this repeatedly: the status is a quality and priority decision, not a broken thing to repair.

Technical causes do exist, and we check them first — near-duplicate templates, thin generated pages, orphaned URLs nothing links to, soft 404s returning a 200. Those are real fixes. But when the page is a thin location variant with 200 words of boilerplate, no technical change will get it indexed. We will tell you that rather than bill for the attempt, and point you at SEO content and copywriting instead.

Core Web Vitals: LCP, INP and CLS

Three metrics, three thresholds, one measurement rule that catches teams out. To pass in 2026, LCP must be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less — at the 75th percentile of real Chrome users, over a rolling 28-day window. Miss one and you fail the whole assessment. Just over half of mobile origins currently pass all three.

That model has two consequences worth planning around. Your slowest quarter of visitors decides the outcome, so a fast experience on your own laptop proves nothing. And a fix needs up to 28 days to work through the field data, which is why we tell clients not to judge a performance release for a month.

Why INP is the one that breaks sites

INP replaced First Input Delay in March 2024, and it is a much harder test. FID measured the delay before the first interaction was processed. INP measures the full latency of interactions across the entire visit, through to the next frame painted. Menus that stutter, filters that hang, forms that lag on validation — none of it registered under FID, all of it registers now.

It is also the metric where a Lighthouse score of 100 tells you nothing, because Lighthouse never clicks anything. Interactive JavaScript sites fail INP with perfect lab scores routinely. The fixes live on the main thread: breaking up long tasks, cutting hydration work, deferring third-party scripts, moving work off the interaction path.

JavaScript SEO for Next.js, React and Headless Sites

Google renders JavaScript. That is not the problem. The problem is that rendering is queued, resource-limited and unforgiving of anything that fails quietly — and that most SEO agencies stop at «make it server-side rendered» and hand the rest to your developers.

This is our own stack. This site runs headless WordPress with Next.js, serving fully rendered HTML from the server, with a clean sitemap, correct hreflang and an llms.txt file. View source before you contact us; every claim in this paragraph is checkable in about thirty seconds.

Next.js: SSR, ISR and the rendering choices that decide indexation

The traps we find most often, in order of how much damage they do:

• Content that exists only after hydration. Fetched client-side in an effect, so the server sends an empty shell. Users see it, Googlebot sometimes sees it, and «sometimes» is the whole problem.
• Metadata set on the client. Titles and canonicals injected after mount. Google usually catches up; AI crawlers, which largely do not execute JavaScript, never do.
• Routing duplicates. Trailing slashes, optional catch-all segments and locale prefixes producing several working URLs for one page, with nothing consolidating them.
• Hydration mismatch. Server and client render different markup, React throws away the server tree and rebuilds on the client. Costs you INP, and occasionally the content Google saw first.
• ISR revalidation set wrong. Either stale pages served for days, or every request falling through to the origin with TTFB climbing behind it.

The same work decides whether AI systems can read you at all. GPTBot, ClaudeBot and PerplexityBot mostly do not execute JavaScript, so content that appears only after hydration is invisible to them. Server-rendered HTML, explicit crawler rules in robots.txt and an llms.txt file are the technical half of answer engine optimization.

Structured Data That Survives the Next Deploy

Schema added by hand to a few pages, or through a plugin that a template change quietly breaks, is worth very little. We implement it in the templates with fields wired to real content, so it stays valid as the site changes instead of needing redoing after every release.

Worth marking up in 2026: Organization with its sameAs links, Product with real availability and price, Article with author and dates, BreadcrumbList, LocalBusiness for physical locations, and Service for what you sell.

Not worth it, if you are expecting rich results: FAQ markup. Google removed FAQ rich results for almost every site in 2023 — we wrote up why FAQ schema no longer earns rich results. It still has some value as machine-readable context for AI answers, which is a different and smaller reason. Anyone selling you FAQ schema for the snippet is quoting 2022.

Site Migrations Without Losing Traffic

Replatforming, redesigning and changing domains are the highest-risk projects in technical SEO, and nearly all of the risk sits in the redirect map. SALT.agency’s 2026 analysis of 1,052 domain migrations found only 27% back to their previous traffic within 90 days, and 13.9% never fully recovered across three years. A clean move typically dips 10 to 30% in the first month and returns to baseline within one to three months.

The variable is not the platform. It is whether every URL that had traffic, rankings or backlinks received a direct 301 to its true equivalent — no chains, no bulk redirect to the homepage, no «close enough» mappings.

How we run one: benchmark everything before anything moves; map redirects by traffic and link value rather than by URL count; QA the staging build for rendering, canonicals and accidental crawl blocks; launch in a quiet window; then watch logs and Search Console daily for the first fortnight. On a clean migration, expect stabilization in 4 to 12 weeks.

What Technical SEO Costs

Technical SEO services in the US, roughly: automated audit reports under $500, genuine SMB audits $1,000 to $5,000, mid-market and ecommerce $5,000 to $15,000, enterprise audits and migrations $15,000 to $30,000 and up. None of the agencies ranking above this page publish a number at all.

The figure that matters is not the audit price. It is whether the fixes are included, because an audit you cannot implement is a document.

• Technical SEO audit — $1,800, 15 business days. Implementation not included. Full crawl, log analysis, render diff by template, field-data review, prioritized backlog. Written for developers to work from, and yours to hand to any team.
• Audit and implementation — from $4,900. Implementation included. The audit, then we ship the priority backlog ourselves: templates, rendering, redirects, schema, speed.
• Technical retainer — $1,600 a month, three-month minimum. Implementation included. Release QA, regression monitoring, Core Web Vitals watch, schema upkeep, continuous fixes.
• Site migration — from $6,500. Implementation included. Benchmarking, redirect mapping, staging QA, launch and eight weeks of monitoring.
• Engineering time outside an agreed scope — $110 an hour.

If you already have developers, we work to your process instead: the backlog goes into your tracker, we open pull requests and stay through review. That route costs less and takes longer.

Technical SEO is the foundation, not the whole campaign. It runs alongside SEO promotion, feeds local SEO services when you rank by location, and only pays off once there is content worth indexing on top of it.