Start with rendering, because it’s the cause most likely to produce a decline that looks like a content or authority problem but isn’t. Pull up Search Console’s URL Inspection tool for a sample of affected pages and compare the “rendered HTML” view against what the CMS actually contains in its admin/source. If content that clearly exists in the CMS is missing, altered, or truncated in Google’s rendered view, you’re looking at a rendering-layer problem, not a content-quality or authority problem, no matter how much the traffic chart looks like a typical algorithmic-update pattern.
Why rendering issues masquerade as content or authority problems
The confusion happens because the symptom, a decline in organic traffic or rankings, looks identical regardless of cause. A page that drops in rankings because Google’s renderer failed to see its main content (a CMS template bug, a broken client-side data fetch, an API dependency that started timing out) produces the same downward line in Google Analytics as a page that dropped because the content genuinely got weaker relative to competitors, or because the site’s overall authority signals softened. Nothing in the traffic graph itself tells you which one happened. The differentiation has to come from checking what Google actually saw and indexed, not from re-reading the content with fresh eyes and guessing it needs to be “better.”
This is a genuinely common failure mode with CMS-driven sites specifically because CMS deploys, template updates, or plugin/module changes can silently alter what’s rendered without anyone on the content or SEO side noticing, since the CMS admin interface itself still shows the content exactly as authored. The disconnect is between what an editor sees in the CMS and what Googlebot’s rendering pipeline actually produces from the live template, and that disconnect is invisible unless someone specifically checks the rendered output.
A practical triage framework
Step one: check rendering fidelity via URL Inspection. For a representative sample of declining URLs, compare Google’s rendered HTML (available directly in URL Inspection) against the actual CMS content and against the raw server response. Look specifically for: content present in the CMS but missing or truncated in the rendered view; canonical tags or meta robots directives that differ between source and rendered output; structured data that’s present in source but absent post-render (or vice versa). Any of these indicate the decline has a rendering component.
Step two: check Crawl Stats for anomalies coincident with the decline. Search Console’s Crawl Stats report shows response codes and response times to Googlebot over time. If a CMS deploy, migration, or infrastructure change lines up in time with the traffic decline, and Crawl Stats shows a corresponding shift (increased 5xx rates, slower response times, changes in crawl volume), that’s a strong signal the cause is systemic and infrastructure/rendering-related rather than content-quality-related, since content quality changes don’t typically produce crawl-stat anomalies on their own.
Step three: check whether the decline is uniform across templates or isolated to specific content. This is the most diagnostic single check available. A rendering or CMS-level problem, because it’s usually tied to a shared template, component, or deployment, tends to produce a decline that’s broad across a whole section, content type, or template family, hitting pages regardless of their individual quality or authority level. A content-quality or authority problem tends to be more uneven: some pages in a category decline while comparable pages with stronger content or better external signals hold up or even improve. If you segment the affected URLs by template/section and the decline is essentially uniform regardless of the individual page’s prior content quality, that points toward CMS/rendering. If the decline correlates with specific content characteristics (thinner pages, weaker backlink profiles, more competitive SERPs) rather than shared template membership, that points toward content or authority causes.
Step four: only after ruling out or confirming rendering, move to content/authority-specific diagnostics. If rendering checks come back clean (rendered HTML matches source, Crawl Stats shows nothing unusual, decline correlates with content characteristics rather than template membership), then the more traditional content-and-authority diagnostic work (competitive content-gap analysis, backlink profile changes, SERP volatility correlated with known algorithm update dates) becomes the more productive next step.
Why the order matters
This isn’t a rigid, universally mandatory sequence, some situations will have an obvious starting point (a known recent CMS migration, for instance, should push rendering checks to the front regardless), but as a general triage principle, checking rendering first is efficient because it’s the cheaper, faster, more binary check: either Google’s rendered view matches your content or it doesn’t. Content and authority diagnostics are comparatively slow, subjective, and easy to rationalize toward whatever hypothesis you started with. Ruling out the mechanical, verifiable cause before investing time in the more interpretive content-quality investigation avoids the common trap of doing a content rewrite to fix a problem that was actually a broken API call in a page template the whole time.
