Rendering diagnosis: source HTML against what Google renders

A JavaScript site that has lost organic traffic has usually not been penalised. In the diagnoses Renderlab has run since 2019, the cause was a rendering fault about seven times in ten: a canonical written by client-side code and read by Google's rendering queue days after the first crawl, an internal link that exists only as an onClick handler and therefore never becomes a discovered URL, or a template that returns HTTP 200 with an empty shell while the API behind it answers 404. None of those appear in a rank tracker. All three are visible within an hour of putting rendered DOM next to source HTML. The question this engagement answers: One question, template by template. Does the HTML Google indexes contain the links, prices, canonicals, hreflang and body copy your team believes it contains, and if not, at which step do they disappear. Answering it means fetching each template three ways: as raw HTML from origin with no JavaScript executed, as a rendered DOM through headless Chrome driven by the DevTools Protocol with the Googlebot Smartphone user agent and a constrained resource budget, and as Google itself reports it through the URL Inspection API. Three views, diffed. Where they disagree, the disagreement is the finding. Who does the work: Both engineers who run Renderlab, on every engagement. One came out of front-end platform work on a Next.js commerce codebase; the other spent six years on technical SEO for marketplaces. We read your code. That is the difference between this and a crawl report: we name the component, the hook and the line where a canonical is being set after hydration, rather than telling you canonical tags need review. Decisions we have made in front of the people who had to live with them: told a fashion retailer to delay a replatform by five weeks because the new product page shipped price and availability only in a client-side fetch; told a B2B SaaS team their prerender middleware had been serving eleven-month-old HTML to Googlebot, and that their decline predated the redesign they were blaming; told an agency that the migration they hired us to challenge was sound, and that their client's problem was a robots.txt rule the agency itself had written. What you receive: A findings document, HTML and PDF, ordered by revenue exposure rather than by a severity label. Each finding names the template, the URLs affected, the mechanism, the fix in the vocabulary your developers already use, and what it is worth, modelled on your own Search Console impressions and your own conversion rate rather than an industry average. A rendering matrix: each template against source HTML, rendered DOM and Google's own render, with deltas marked. One recorded hour with your engineering lead, where we take the argument rather than present slides. Expect disagreement. The fix usually costs sprint capacity somebody has already promised elsewhere. Not included: We do not write the fix. No commits to your repository, no release management, no supervision afterwards. If you want implementation, use your own team or ask us for a name; we will give you one and take nothing for it. We do not audit content, keywords or backlinks. This is a rendering engagement. If your pages render correctly and still do not rank, the answer is not in here. Who this is not for: Sites with a handful of distinct templates. The finding will be one paragraph and you will have paid for a document. Teams that cannot ship a change to production inside a quarter. A report ages badly, and a fix nobody can deploy is just a receipt for a problem. Anyone who needs the conclusion agreed beforehand. Twice we have concluded the rendering was sound and the traffic loss came from a decision the buyer's own leadership had taken. We said so and charged in full. Timing and access: Two weeks from access. Access means a live URL for every template, read access to the repository or a walkthrough with a developer, Search Console at owner level, and thirty minutes with whoever can answer why it is built this way. The fee is fixed before we start. We do not bill by the URL, because the number of URLs has almost nothing to do with how hard the answer is to find.