Twelve and a half percent of that catalog was indexed.The rest was not ranking badly. It was not competing.
Technical SEO services for sites where the content is fine and the results are not. We find the reasons engines cannot reach, read or attribute your pages, and we fix them in the order that matters.
We are a small agency, not a tool. Site audit software produces four hundred issues sorted by its own severity scale. Deciding which three actually matter on your site, and proving the fix reached the crawlers, is the work.
Everything else you buy assumes this works
What people buy first
Content, keywords, AI visibility, a new design. The visible things, and the things with the nicest reports.
All of them assume the engines can reach, render and index the pages underneath.
What decides whether any of it works
Whether the engines can reach, render and index the pages underneath.
If 87% of your catalog is not indexed, it is not ranking badly. It is not competing at all. No amount of writing changes that.
This is why on-page work, answer engine optimization and generative engine optimization all point back here. A better title on a page nobody can index changes nothing.
It applies just as directly to a product catalog, where indexation decides how much of it competes at all, and to location pages, which fail at existing far more often than they fail at ranking.
Four questions, in this order
Can they reach it?
Crawl paths, robots rules, redirect chains, server responses, and whether every entry point to your domain actually resolves. The unglamorous layer where the expensive failures live.
Can they read it?
Rendering. If your content, your navigation or your structured data only exists after JavaScript runs, half the engines that matter in 2026 never see it.
Is it indexed?
Not submitted. Indexed. The difference is the whole game, and on a large catalog the gap between the two is usually the single biggest growth lever available.
Does it resolve to you?
Canonicals, duplication, and structured data that identifies the business consistently. A machine that cannot tell which page is authoritative cannot attribute anything to you.
The order matters more than the list. Fixing rendering before crawling, or schema before indexation, produces no compounding. Each layer depends on the one beneath it, which is why a findings list sorted by a tool’s severity score is usually the wrong plan.
Two diagnoses from live accounts
Both were invisible in every report the client was reading. Neither needed a single word of new content.
Diagnosis one: the domain nobody could reach
Only the www version of the site resolved. Every other entry point failed.
The bare domain returned a gateway timeout. HTTPS on the apex refused the connection outright. An HSTS policy then forced browsers to HTTPS on a host with no HTTPS listener, which turned a broken address into an unrecoverable one for anyone who had visited before.
Anyone typing the domain from a business card, an email signature, a printed catalog or the Google listing hit a dead page. Every backlink and citation pointing at the non-www domain passed nothing at all.
The site had been in that state indefinitely. It was found, traced to a DNS record, and fixed. No content was written.
Diagnosis two: schema the AI crawlers could not see
A client’s entire organization schema existed only after JavaScript ran.
It had been delivered through a tag manager. Google renders JavaScript, so Google saw it. GPTBot, ClaudeBot, PerplexityBot and CCBot generally do not.
The only machine-readable statement of who that company was could not be read by a single one of the engines their AI visibility work existed to reach. The fix was serving it from the server. Confirmed afterwards by direct fetch and by a headless render, because assuming it worked is how this happened in the first place.
What fixing the foundation looked like
A distributor arrived with 754 of more than six thousand pages indexed. Traffic was falling rather than flat. Measurement was worse than the content: the tag manager had never been installed, and ecommerce tracking was switched off on a site that sells.
Share of one distributor site Google had indexed
Today 98.84% of that site’s sitemap URLs are indexed, and the property runs over eight million search impressions a year.
What those two percentages are out of, because they are not the same denominator. The first is indexed pages against total pages on the site, from the original audit. The second is indexed URLs against the URLs the sitemap submits, from Search Console. Both measure whether the catalog is eligible to compete, which is the point, and we are showing you the difference rather than hiding it inside one number.
What you will see, and when
Indexation, crawl and render findings are observed states, not estimates. They do not need a 28-day window and we do not pretend otherwise.
New pages built and submitted this way are routinely indexed the day they ship, sometimes within minutes.
The traffic consequence of fixing the foundation, read against a control where one exists.
Who this is for, and who it is not
It fits large catalogs, sites that have been replatformed or rebuilt, JavaScript-heavy builds, and any site where content investment has stopped producing a return for reasons nobody can name.
We will say no when:
- Your indexation is already healthy and your pages render server-side. Then the problem is not technical and we will point you at the thing that is.
- Nobody can change the site. If findings cannot be implemented, a diagnosis is an expensive document.
- You want a tool report. Several good ones exist, they cost a fraction of this, and we will name them.
- The site is small and simple. Under a few hundred pages with a standard build, the return usually does not justify the work.
The same structural work also decides whether your site is usable by someone using assistive technology, which is web accessibility. Not sure which of these is your problem? That is what an SEO audit is for: it gathers the evidence, and the assessment tells you which finding is the cause and which are symptoms of it.
Questions we get asked
Q. What actually counts as technical SEO?
Everything that decides whether a search engine or an AI crawler can reach your pages, render them, understand them and attribute them to you. Crawl paths and robots rules, server responses and redirects, rendering and JavaScript dependency, indexation, canonicals and duplication, structured data, site speed and Core Web Vitals. It stops where the words begin. What the page says is on-page SEO and it is a different service.
Q. How do we know if we have a technical problem?
The usual symptom is that everything else stopped working. Content is published and nothing happens, rankings drift without an obvious cause, or a large catalog produces a fraction of the traffic its size suggests. The fastest single check is indexation: compare the number of pages on your site with the number Google has actually indexed. If that ratio is poor, nothing downstream is worth buying yet.
Q. Is this a one-off audit or an ongoing program?
Usually a bounded diagnostic first, because most technical problems are discrete and fixable rather than continuous. It ends with a prioritised list in dependency order and you can hand it to your own developers. Ongoing monitoring makes sense for large catalogs and for sites that deploy frequently, where new problems arrive with each release. We will tell you which case you are in rather than defaulting to a retainer.
Q. Do you fix it, or just tell us what is wrong?
Both, depending on access and on what your team prefers. We work alongside your developers rather than around them, which matters because the people who maintain the site need to understand why something changed. Handing over a PDF and leaving is how the same problems come back in eighteen months.
Q. Why does JavaScript rendering keep coming up?
Because it is now the most expensive assumption in technical SEO. Google renders JavaScript, so a site can look perfectly healthy in Search Console while being close to invisible to AI crawlers, which largely do not. We have found a client’s entire organization schema in exactly that state: present for Google, absent for every answer engine their AI visibility work was meant to reach.
Q. How fast can pages get indexed?
New URLs built and submitted properly are routinely indexed the same day, and in one measured case about two minutes passed between requesting indexing and the page being indexed. The honest boundary is that this applies to new pages. Getting an engine to re-crawl an existing page that has changed is a different and slower problem, and anyone promising speed on that is guessing.
Q. Will fixing this increase our traffic?
It removes the reasons you cannot compete, which is not the same promise. On a site where 12.5% of pages were indexed, fixing the foundation was the difference between a catalog that could rank and one that could not, and that site now runs over eight million search impressions a year. On a site with no indexation problem, technical work will not move traffic much and we will say so before you buy.
Q. Do you work with our developers or replace them?
With them, always. Most of what we find is a configuration decision rather than a coding problem, and the people who own the platform are usually the fastest route to a fix. We write the diagnosis so a developer can act on it without translation, and we verify the fix live afterwards rather than assuming the ticket closing meant it worked.
Q. How is this different from running a site audit tool?
A tool produces several hundred issues sorted by its own severity scale. Most of them do not matter on your site, and the one that does is usually not at the top. The work is deciding which findings are load-bearing for your business, in what order they should be fixed, and verifying afterwards that the fix actually reached the crawlers. We use those tools. They are the start of the job, not the job.
Start with a conversation
Thirty minutes, and the indexation check takes about two of them. If your catalog is already fully indexed and rendering server-side, we will tell you that on the call and you will have saved yourself a project.