Crawl and render audit, delivered as a ranked defect register

On sites above 100,000 URLs the defect that costs the most traffic is almost never the one at the top of an audit tool's critical list. Across our last eleven engagements the largest recoverable loss fell into the same category every time: URLs that return 200 with a shell of HTML, get queued for rendering, and wait days behind the rest of the site before Google sees content the CMS delivered to a human being instantly. This engagement finds that class of defect on your site, states how many indexable URLs it touches, and hands the fix to your engineers in a form they can estimate. The question this answers: Which technical defects are costing you indexed pages right now, and in what order should engineering fix them given what each fix costs to build? That is not the same question as what is wrong with this site. Every site at this size has hundreds of things wrong with it and almost all of them are irrelevant. The register you receive ranks each finding by the indexable URLs affected and the search demand sitting on them, then weighs that against an engineering estimate we agree with your team before delivery. Findings that cost more to fix than they return stay in the register, marked, with the arithmetic shown. Who does the work: Both partners at Northpeak, personally. Thirteen years between us on crawl and render problems, six of them in house at a German marketplace where the render queue was a standing item with the platform team. We have argued with an engineering director about server-side rendering budgets, lost the argument, and been proved right eighteen months later at considerable cost to the client. That is the experience that makes the recommendation list short. Work runs in English or German, whichever language your engineers hold standups in. How it runs: The first phase compares raw HTML against the rendered DOM for a stratified sample of your templates, field by field: canonical, title, hreflang, internal links, main content, structured data. Divergence between the two is where indexation goes wrong, and it stays invisible to any tool that fetches only one of them. Alongside that we pull URL-level Search Console data, your sitemap set, and thirty days of server logs if you can get them. The second phase reproduces each finding down to a cause in your stack. Duplicate titles is not a finding, it is a symptom. The finding is that the listing template writes its title from a filter parameter which is stripped before render on cached responses, affecting the 34,000 URLs behind facet combinations. The third phase is the register, the walkthrough, and the disagreement that follows it. What you receive: A findings register as a spreadsheet, one row per defect, carrying the affected URL pattern, a reproduction, the cause, a fix at code level, and the count. A written document covering the four or five findings that decide the year, for the people who will not open a spreadsheet. Two calls, one commercial and one technical, run separately because merging them wastes both rooms. Tickets written into your tracker in your own format if you want them. What is not included: We do not implement. No pull requests, no CMS changes, no CDN configuration. This engagement ends at the ticket. Content, links, keyword strategy and paid search sit outside it. We do not produce competitor comparisons. We will not certify a site as sound for a board or an acquirer, and we do not sign off on a migration plan we did not test. When the answer is inconvenient: About one engagement in four ends on a finding nobody wanted. The replatform already scheduled will reintroduce the same defect. The largest available gain needs a URL structure change product has refused twice. We put it in writing with the number attached, because the number is what you are paying for and agreement is not. If the conclusion is that your technical setup is sound and the problem is demand or content, you hear that in week one and the billing stops there. Who this is not for: Sites under roughly 50,000 URLs, where a competent generalist with Screaming Frog reaches the same findings for a tenth of this. Teams with no engineering capacity in the next two quarters, because a register nobody can act on is expensive paper. Anyone who needs the deliverable to conclude that the current setup is fine.