Ten thousand pages, three days of budget: where to start

A client hands over a shop with ten thousand pages, and the budget covers three days. The crawl runs overnight and reports 38,000 findings in the morning, sorted by severity. Work that list from the top and you spend the first day on alt texts for product images and go home on the third evening without having touched the redirect loop that keeps four category pages out of the index. The mistake is not what is expensive. The order is.

How to go about it in JMX

1. Settings → Crawl — limits before you start. Exclude URLs takes a regular expression; in shops it catches the faceted navigation that turns two hundred products into six-figure sets of addresses. Concurrent requests: five is reasonable for most servers, two on small hardware.
2. Settings → Segments — store shop, blog and careers as patterns before you read the first finding. Every page belongs to the first segment that matches, so the order of the definitions is part of their meaning. Whatever matches none of them collects under the entry for pages without a segment.
3. The Technical tab — eight core questions on one page: crawler access, robots.txt and sitemaps, indexability, redirects, load times, language codes and security headers. What could not be checked is called “Not checkable” there and not “Fine”.
4. The Issues tab — above the rule list sits the breakdown by segment with the findings per page column. It is the only number that makes a shop with ten thousand pages and a blog with thirty comparable.
5. The Tasks tab — four tiles: Do now, Schedule, Alongside, Defer. Your three days are in “Do now”. The At most filter hides everything that costs more work per finding than a chosen level; sorting is by field first and only then by leverage — points per person-day.
6. Export — PDF for the client, an Excel workbook to tick off. What is written out is what is on screen, filters included; the numbering stays that of the whole plan.

What to watch out for

The Impact column is regularly misread. It is the score calculation without capping and says what a finding currently costs the score — not how many points become visible after fixing it. A site sitting at 0 will see nothing rise for a long time. Leverage alone is no ranking either: a plain quotient would put a task worth 0.2 points in ten minutes above one worth twelve points in three days.

The effort is an estimate: six minutes for something trivial, a good twenty for a short text, an hour and a half for real work on a page, three quarters of a day for a project. Only what structurally sits in one place counts as one-off — robots.txt, server configuration, language markup in the shell. Everything else JMX counts per page, because that is the cautious direction. If your shop generates 8,000 descriptions from one template, the row overestimates the effort considerably, and the task slips too far down.

What the list does not know: which of the ten thousand pages bring in money. It weights by points and effort, not by clicks — sorting by real traffic is what the migration view does (severity times click volume from Search Console) and what the page assessment does, ordering each action by the impressions at stake. And if you capped the crawl via Maximum URLs, the rules that argue from an absence go quiet: “orphan page with no incoming internal links” and “sitemap URL never reached in the crawl” are not reported at all on a capped run, because the absence then says something about the crawl and not about the site. Only the duplicate search keeps going — on the subset, and without a note on the result to remind you.

Three days are not enough for ten thousand pages. They are enough to settle what the next twenty get — and that decision then sits with the client as a PDF, with effort and effect on the same line, instead of as a memory of a conversation.