Technical SEO Services That Show You the Log, Then Prove the Fix
A site that will not index is not a mystery. It is a status code, a blocked path, or a rendering gap — all of which appear in a log. We find it, fix it, and hand you a before-and-after crawl you can check yourself.
- crawl --compare before.xml after.xml · index delta by URL pattern
- render --both · raw HTML versus rendered DOM, link by link
- chain --follow · every redirect hop counted and collapsed
- canonical --conflicts · self-referencing, cross-language, non-200 targets
- verify --retest · the same check re-run after deployment
// crawl access only, no CMS login needed for the diagnosis
"Discovered – currently not indexed" is a symptom, not a sentence
Search Console gives you a label. It does not tell you which of nine causes produced it. Below is the crawl log from a store with 12,840 URLs and 318 indexed pages — and the four causes that explain it.
/collections/valveskeep · target page, needs links/valves → /valves/ → /valves-2/ → /c/valvescollapse to one hop/product/old-sku-114map to replacement or 410/search?q=washerkeep 410 · remove from sitemap/catalog?page=48server timeout under crawl load/collections/* (nav rendered client-side)server-render the menuFour of those six rows are the same disease: the crawler is being sent places it should not go, and blocked from the places it should. That is why "add more content" does nothing for this site. It has content. It has a routing problem.
Five faults that account for most technical traffic loss
Not theory. These are the five we find in the majority of audits, in roughly this order of frequency.
Requests spent where nothing converts
Filter paths, site search, pagination into oblivion, session IDs, calendar widgets, print views. Each is cheap alone; together they consume the requests that should be reaching category and product pages.
check: server logs, requests by directory, index coverage by pattern.
Content only exists after JavaScript runs
Menus, product grids, specification tabs and internal links generated client-side. Google may render it eventually; users and other crawlers may not. Anything the site depends on should be in the initial HTML.
check: view-source versus rendered DOM, URL inspection's rendered snapshot.
Chains that leak authority and patience
Three hops is a warning; six is a bug. Chains accumulate after migrations and platform switches, and they usually point at a final URL that also has a canonical problem.
check: crawl with redirect following disabled, count hops per URL.
Conflicting canonical signals
A canonical pointing to a redirect, to a 404, or to a different language version contradicts what hreflang says. When two directives disagree, search engines pick one and ignore you.
check: canonical target status, canonical versus hreflang return tags.
Sitemap, robots and server behaviour
Sitemaps listing redirects and 404s. Robots blocking CSS and JS that the page needs to render. 5xx responses when a crawler requests 50 pages in a minute. All invisible in the browser, fatal in the index.
check: sitemap status sampling, robots fetch test, crawl-rate response codes.
Core Web Vitals that fail on templates
LCP on the hero image of a category page. CLS from a late webfont. INP broken by a chat widget. Vitals are template-level problems, so one fix moves thousands of URLs.
check: field data by template group, then element-level attribution.
The redirect chain nobody noticed
A real sequence from a migration that "went fine". Six hops, 1,204 pages affected, and the final target says it is not the canonical version of itself.
The fix took forty minutes. Finding it required a crawl that did not stop at the first redirect — most tools report the first hop and call the URL "redirect", which hides the chain entirely. If your last audit said "1,204 redirects, low priority", it stopped one step too early.
hreflang, canonical and the three-way conflict
Multi-language sites fail in a specific, repeatable way: three directives disagree about which page is the original. Search engines resolve the disagreement by choosing one, and the pages you care about lose.
What it looks like
page: /de/produkt/ventil-40
canonical: /en/product/valve-40
hreflang: de-DE → self, en-GB → /en/valve-40
The canonical says "the English page is the original". The hreflang says "this German page is a German original". Both cannot be true. Typically the German page drops out of the German index while the English one fails to rank in Germany either.
What we change
Each language version becomes self-canonical. Hreflang return tags become reciprocal and complete, including x-default. Language and region codes follow ISO, not a guess. Sitemaps split by language with accurate lastmod dates.
verify: hreflang validator on a full crawl, not a sample of ten links; index coverage per language folder; return-tag symmetry check.
A fix is not finished until it is re-tested
This is the part most engagements skip, and the reason clients tell us they "already tried technical SEO". Every change we ship carries a verification step that produces a number.
| change | retest method | pass condition |
|---|---|---|
| robots.txt | Fetch test in Search Console plus a fresh crawl of the blocked path | 0 unintended blocks; sitemap URLs crawlable |
| redirect map | Full crawl with hop counting, curl -I on 200 samples | max 1 hop; no chain over 3; 0 loops |
| canonical tags | Crawl extraction of canonical, then status check on each target | 100% self or valid 200 target |
| server rendering | Raw HTML fetch versus rendered DOM, link count diff | critical nav and product links present raw |
| sitemap | Sample every URL pattern, check status code and indexability | only 200, indexable, canonical URLs |
| Core Web Vitals | Field data after 28 days, per template group | LCP under 2.5s at 75th percentile |
| hreflang | Full-site return-tag symmetry check after deploy | no orphan or mismatched pairs |
If you have been told a fix is "done" without a number attached, it is a claim, not a result. We send the crawl diff as a file so your own team can reproduce it.
How an engagement runs
Four phases, ten working days for the diagnosis, then delivery in the order that unblocks the most revenue fastest.
Baseline capture
Full crawl, log sample, render comparison, index coverage by pattern, vitals by template. Everything is recorded before a single change, so the before-state cannot be argued about later.
Fault ranking
Each fault gets a URL count, a severity and a fix cost. Template-wide faults outrank single-page ones, always, because they unblock the most URLs per hour of developer time.
Implementation or tickets
We either ship the change ourselves or hand your developer an exact patch with the file, the before/after markup and the retest command. Both paths are normal.
Retest and diff report
The same crawl, the same checks, run again after deploy. You get the delta, plus any new fault the change introduced — migrations create them constantly.
Watch period
Four weeks of monitoring for index movement and vitals field data, with a short written note each fortnight. If a number does not move, we reopen the diagnosis at no charge.
What the retest changed
Three engagements, masked clients, numbers pulled from Search Console and server logs.
"Nine thousand URLs were blocked by a robots rule left over from a staging push. Nobody could see it because the pages loaded fine for us."
Industrial components · US"The category hero was a 2MB PNG served at full resolution on mobile. The template fix moved vitals on 4,200 URLs in one deploy."
Furniture retailer · UK"Before, Googlebot spent most of its day on filters. Two months later it was reading categories, and organic revenue followed."
Auto parts distributor · CASend the domain. We will run the crawl first.
A read-only crawl needs no access from you. You get the top three faults with URL counts before any invoice exists.
Scope-based quotes, itemised by fault
Technical work is measurable, so it is quoted by the job rather than by the month. You see a line per fault class, the estimated hours, and whether we ship it or your developer does.
Audit and retest baseline
Full crawl, log sample, render comparison, index coverage, vitals by template, and a ranked fault list with URL counts. The retest crawl is included, not sold separately.
Fix and prove
Implementation of the ranked faults: robots and sitemap corrections, redirect consolidation, canonical alignment, server-side rendering for critical nav, template vitals work. Priced by the fault set, with the retest diff in writing.
Clients who want to understand the underlying pipelines before commissioning anything usually start with Google SEO Services — it explains why crawl, render and index are separate failure points.
Questions that come up in the first call
How long until indexing improves?
Crawl-blocking and redirect faults usually show up in the index within two to four weeks, because Google recrawls cleared paths quickly. Rendering changes take longer — expect four to eight weeks before the rendered links are consistently followed.
Do you guarantee a full index?
No. Not every URL deserves to be indexed, and we will tell you when the answer is to remove pages rather than rescue them. Nobody can promise a specific indexed count.
We already had a technical audit. Why did nothing change?
Usually because the audit ended at the diagnosis and no one owned the implementation, or because the fixes were applied without a retest and silently failed. Ask for the crawl diff. If there is no diff, the work was never verified.
Can you work with our developers directly?
Yes, and it is our preferred model on large platforms. We write tickets at pull-request level: file path, current markup, replacement markup, and the exact check that proves it worked.
What access do you need?
For the diagnosis, none beyond the public site — a crawl is read-only. For fixes, repository or CMS access, or a developer contact. Search Console access helps us compare against Google's own view.
Is migration support included?
As a separate scope. Pre-migration we map every URL and its destination, post-migration we diff the live crawl against the map. Most migration losses we see are caused by skipped pre-migration mapping, not by the platform.
Who runs the crawl
Two engineers, no account managers. Between them: eleven years of crawl and rendering work, five platform migrations on catalogues over 50,000 URLs, and daily work in server logs rather than dashboards. English-language markets only — US, UK, Canada, Australia, EU.
We keep a written record of every baseline crawl, so that six months later, when a template changes again, the comparison is still possible. That record is handed over whether or not you continue with us.
Direct lines
WhatsApp: +8618465139145
Telegram: @bdtg678
// first reply usually within three hours during EU business hours