Technical SEO in code
Crawling, indexing and structured data fixed at the template level.
Canonicals, hreflang, pagination, structured data, redirect chains, render-blocked content and sitemap logic, corrected in the templates rather than patched with a plugin. This studio started in SEO before it started in code, and still builds sites that way.
Project pricing
From $2,000
That covers the crawl, the written diagnosis and the template fixes it names. Large catalogues, several languages or a migration to repair run to $9,500.
Send the brief and get a number back.
Describe the projectThe pages are live and Search Console says they are not indexed
The sitemap lists them, the browser loads them, and the coverage report says crawled and not indexed, or discovered and not crawled, or duplicate without user-selected canonical. Nobody in the room can say whether that is a technical fault or a verdict on the content. Meanwhile a redesign moved every URL, a plugin is emitting a canonical that argues with the one in the template, and half the product copy only exists after JavaScript runs. The honest first question is which of those is actually costing you traffic, because the answer changes what should be paid for.
What the work covers
A crawl, not a checklist
The site gets fetched the way a crawler fetches it and compared against the sitemap, the coverage report and what a browser shows. That is how the real problems surface: pages returning one thing to a bot and another to a person, parameters multiplying into thousands of near-duplicates, redirect chains eating link value, and content that only exists after a script runs.
Fixed in the template, not with a plugin
Canonicals, hreflang, pagination, robots directives and structured data get emitted by the layer that owns the page. Plugins layered over a theme produce two tags where there should be one, and a crawler resolving the conflict is not a crawler you control. Corrections go where the page is generated, which is also why they survive the next theme update.
Measured against Search Console, not against a score
Before and after are read from your own property: impressions, indexed pages, the queries that moved, the pages that came back. A third-party audit score is a proxy for what a tool can measure cheaply and is not the thing you were trying to change.
Why it is done this way
Technical SEO removes obstacles, it does not create demand
If nobody searches for what you sell, flawless markup changes nothing, and you should hear that before you spend on it rather than after. What this work does is make sure the demand that exists can reach you: pages crawlable, indexable, not competing with themselves, and rendering what they promise. That is a real and often large gap. It is also a ceiling, and where the ceiling is demand rather than crawlability, that gets said out loud.
A score out of a hundred is not a ranking
Audit tools grade what is cheap to measure: heading order, image attributes, a lab performance number from a single synthetic run. Pages that rank routinely fail those checks, and pages that pass them routinely rank nowhere. The useful output is not a higher score, it is fewer pages excluded from the index and more of them serving the query they were written for.
How it runs
Read access to Search Console and Analytics, plus the site itself. Without the first two this is guesswork dressed as an audit.
A crawl of the live site compared against the sitemap and the coverage report, with findings ranked by how many pages and how much traffic each one touches.
A written plan that separates the three kinds: template faults worth fixing, content verdicts that need writing rather than code, and things that are technically wrong but cost you nothing.
The fixes land in templates and configuration, on staging first where the platform allows it, then live with the crawl repeated to confirm.
A follow-up read of the property a few weeks later, because indexing changes take weeks to show and anything claimed before then is a guess.
Background
What technical SEO is and where it stops
Crawled and not indexed is usually a verdict, not a bug
This status is the one that sends teams looking for a technical fault that is not there. It means the page was fetched, read and set aside. Sometimes the cause is mechanical: a near-duplicate of another page, a thin template repeated across hundreds of URLs, a page reachable only through a parameter. Often it is editorial: the page exists but adds nothing that is not already indexed elsewhere. The distinction matters because one is fixed in code and the other is fixed by writing something worth keeping, and only one of those is a developer's job.
Where the tags start arguing
Most sites carry more than one thing that wants to emit head tags: the theme, an SEO plugin, a translation layer, sometimes an app. The result is two canonicals, an hreflang set that points at pages returning 404, a robots directive nobody remembers adding, and structured data describing a product that is no longer on the page. None of that throws an error. The crawler simply resolves the conflict on its own terms, and the resolution is often not the one you wanted. Deciding which layer owns the head is the fix, and it is architectural rather than a setting.
Core Web Vitals after the metric changed
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, which moved the target from how fast a page acknowledges the first tap to how long the interface actually takes to respond. Stores that tuned for the old metric can score worse now without changing anything, particularly where third-party scripts block the main thread on interaction rather than on load. The measurement that counts is field data from real visitors, not a lab run on a fast connection, and those two disagree more often than they agree.
What this work cannot do
It cannot create search demand, it cannot make a page deserve a position it does not deserve, and it cannot recover a site that lost visibility because the content is not competitive. Saying so is part of the service, because the alternative is a retainer that bills for crawl efficiency on a site whose problem was never crawlability. Nine projects in the portfolio carry this work, in the United States, the United Kingdom, Canada, Israel, Ukraine and worldwide, and it started before the code did: this studio worked in technical SEO before it built anything.
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
Technical SEO, asked and answered
Often, and quickly, if it is a migration fault. The usual causes are old URLs returning 404 instead of redirecting, redirects that chain three deep, canonicals pointing at the old structure, and a sitemap that still lists what no longer exists. Those are mechanical. If the drop coincides with an algorithm update instead of your launch, that is a different conversation and the honest answer may be that no amount of markup restores it.
Unknown, and that is the problem with the number. The score mixes things that matter with things that do not, weighted by what the tool can measure. A site can score 95 and be invisible because every page is a near-duplicate. What the score is genuinely useful for is finding candidates to check, not for deciding what to fix.
Up to a point. They are real signals, they are measured on your actual visitors rather than on a lab test, and Interaction to Next Paint replaced First Input Delay in March 2024, so a store that tuned for the old metric may be worse than it thinks. What they are not is a ranking lever that outweighs relevance. Fix them because slow pages lose orders, and take the search benefit as a side effect.
No. Anyone who does is guaranteeing an outcome decided by a system they do not control and do not see inside. What can be promised is that pages become crawlable, indexable and non-competing, that the fixes are made where they hold, and that the before and after come from your own Search Console rather than from a dashboard we designed.
Usually content, once the technical floor is not actively blocking you. Technical work has a ceiling and content does not, which is why the diagnosis says plainly which side your problem is on. Spending months on crawl efficiency for a site whose real issue is that nothing answers the query is a common and expensive mistake.