demo.ivanets.co

4–5 weeks with one dedicated developer and one QA engineer

Findings fixed in the same place are costed once: the largest at its full size, each additional one at a day. Sizes are S 1, M 3, L 8 developer-days, reduced where a finding affects only a handful of pages.

Elapsed time is per developer, and the streams above are largely independent: two developers splitting them finish in roughly 2–3 weeks. Assumes 4 productive days per week with QA running alongside development rather than after it. Indicative only: it assumes a developer already familiar with the platform and a normal release cadence. Your team should re-estimate against its own velocity.

Each row above is broken into individual stories, one per finding, with acceptance criteria — see the findings below.

This estimate covers the template, metadata, sitemap, structured-data and redirect work detailed below. It does not cover server-rendering the navigation and page content — that is a change to how the front end is built, and it needs its own discovery before anyone can size it honestly. Completing everything in this estimate will materially improve indexing and crawl efficiency; it will not by itself put the page content into the server response.

Navigation not in server HTML

277 of the 467 crawled URLs have no internal link in any page’s server-delivered HTML — navigation is client-side. It also explains the one further check reporting against nearly every page: it looks for something the server response does not contain. That check is listed below but counted once — No breadcrumb structured data, on 467 pages.

Fixing this is a change to how the front end is built and needs its own discovery, which is why it is not covered by the estimate above.

This is a free sample: 10 findings in detail out of 37. Every sitemap entry was checked, so these are counts rather than estimates. The complete audit crawls the whole sitemap and follows internal links beyond it.

10 shown · 37 found.

curl -s https://demo.ivanets.co/sitemap.xml | grep -oE '<loc>[^<]*</loc>' | grep -vE '<loc>https://[^ <]+</loc>'
# expected: no output

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

curl -s -o /dev/null -w "%{http_code}\n" https://demo.ivanets.co/catalogue/cooking/built-in-ovens/ardvane-aurora-200-oven/p/KV-900000
# expected: 410

HTTP/1.1 410 Gone
Content-Type: text/html; charset=utf-8

# Fetch a listing and count the product links in the raw HTML.
curl -s https://assets-cdn.kelverton-demo.invalid/catalogue/cooking/hobs/ardvane-aurora-200-hob/p/KV-600000 \
  | grep -o 'href="[^"]*/product/[^"]*"' | sort -u | wc -l
# expected: the number of products the page displays, not 0

A number matching the products shown on the page.
Today this returns 0 on listings that build their grid in the browser.

curl -s https://demo.ivanets.co/catalogue/cooking/built-in-ovens/belquist-ransom-189x-oven/p/KV-100018 | grep -o '"\(name\|image\|price\|priceCurrency\|availability\)":' | sort -u
# expected: all five present

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

"offers":{"@type":"Offer","price":"…","priceCurrency":"UAH","availability":"…"}

Stop emitting sitemap entries that are not valid URLs

curl -s https://demo.ivanets.co/sitemap.xml | grep -oE '<loc>[^<]*</loc>' | grep -vE '<loc>https://[^ <]+</loc>'
# expected: no output

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

54 URLs needing a redirect, a removal, or a decision

Every URL below is classified by what it does now. Where a successor could be identified it is named and resolved; where none could be, the row says so and recommends removal or review rather than guessing. A catalogue export is what turns the review rows into named successors.

Whether a retrieval bot can fetch, parse and quote these pages.

A separate score, reported beside the technical one and never folded into it — the two have different owners and different fixes. It is measured the only way a crawl can measure it: with HTTP requests. It is not a measure of how often the brand appears in AI answers, which needs a prompt set rather than a crawler.

• Assessed on 467 pages, from the server response only — JavaScript is not executed.
• robots.txt access is resolved per user-agent, against the paths assessed rather than every URL on the site.
• The live user-agent probe was not run, so band A rests on robots.txt alone.
• The score measures removable obstacles. It does not predict whether the site will be cited in an AI answer.

85 of 100 is the "good" band — 90 and above is healthy, 80 good, 65 needs improvement. Band A carries weight 45 because a bot cannot quote what it cannot fetch, and bands B and C are moot where A fails. Every vendor score of this kind is proprietary and none are comparable to each other. A site can score well here and still never be cited.

Scope and limits.

• 6 sitemap entries were excluded from the crawl because they are not valid URLs. They are reported as a finding rather than scanned.
• Product pages: all 342 URLs in the sitemap were scanned.
• Other pages: all 108 URLs in the sitemap were scanned.
• Category pages: all 43 URLs in the sitemap were scanned.
• Homepage: all 1 URLs in the sitemap was scanned.
• URLs that were removed and also taken out of the sitemap cannot be found by this scan. They need internal-link crawling, a Search Console export, or a catalogue export.
• The crawl was paced to one request every 0.7 seconds across all workers — a deliberate ceiling, not a limit the site imposed.
• Successor redirects are judged on URL shape alone — same section, same depth. That is a structural signal, not a confirmation that the destination sells a comparable product.
• The internal link graph was built from links found on the 494 pages scanned. Links from pages that were not scanned are not in it, so inbound-link counts are a floor rather than a total.
• Orphan detection and crawl depth are not reported: 277 of the 467 crawled URLs that could carry an inbound link have none in the server HTML. That is reported as client-side navigation rather than as orphans, because at that scale the links are missing from the HTML rather than from the site.
• Internal links were collected but not followed beyond the sitemap. Pages that are neither listed nor linked from a scanned page cannot be discovered by this scan. The complete audit follows internal links beyond the sitemap.
• Server-delivered HTML only — JavaScript is not executed.
• Core Web Vitals are origin-level field data from the Chrome UX Report, aggregated across the site over the preceding 28 days. URL-level field data was not available, so these figures describe the origin rather than any individual page.
• No keyword ranking, backlink or Search Console data is included.

* 75 of 100 is the "needs improvement" band — 90 and above is healthy, 80 good, 65 needs improvement. It is an average of page content: the 48 checks that run on every page in a full-site audit. A further 19 — Core Web Vitals, sitemap and broken-link checks — are reported at site level instead, so the figure cannot reflect them. A site can score well here and still be badly indexed, which is why the findings above it matter more than the number.

You are reading the free sample: 10 findings of 37, across 100% of the sitemap.

This site is small enough that the sample covered all of it. On a larger catalogue the sample is a slice, and the complete audit is what makes the counts totals.

Prices are published at ivanets.co/pricing.

Closing a story is a measurement, not an opinion.

Every acceptance criterion in the backlog is an HTTP-observable outcome.

Once your team has released, the same crawl runs again over the same 494 URLs. Each story returns pass or fail, with the response that proves it. Anything that regressed elsewhere on the site is flagged in the same crawl.

The output is a verification report: story by story, what was claimed, what was measured, and the evidence. Use it for internal sign-off, share it with stakeholders, or pass it to a client where that applies.

One verification crawl is included. Where the fixes land across several releases, it can re-run after each — up to three crawls, within 90 days of delivery.

Nothing, to commission it.

The sitemap is public and already crawled.

A product-catalogue export turns the redirect map from decisions into instructions — dead URLs matched to successor SKUs and issued as 301s, instead of 410 with a note. Without it roughly 50 rows stay as 410-or-review. It also splits the 18 out-of-stock pages into returning and discontinued, which cannot be told apart from outside the business.

Read-only Search Console access orders the backlog by traffic actually at risk rather than by page count, so the expensive things get fixed first.

Either can arrive during the five days. Data is read-only, held only for the engagement, deleted on delivery. I am happy to sign an NDA where required.

Commission it, or ask a question — artem@ivanets.co