Isolate the cause by testing the two variables independently: hold the template constant and audit the underlying data for accuracy, freshness, and completeness gaps first, and separately audit the template and rendering output itself for structural problems like thin content or a high ratio of boilerplate to unique substance, rather than assuming one or the other is responsible without checking both. This is standard SEO diagnostic methodology, segmentation and isolation testing applied to a programmatic context, not a workflow Google has published or endorsed; there’s no single authoritative source describing this exact process because it’s practitioner methodology, not Google doctrine.
Step one: audit the data with the template held constant
Since the template is shared across every page in the set, if the data itself has degraded (gone stale, developed gaps, started containing errors), that degradation will show up across the affected pages regardless of how well the template is structured. Spot-check a sample of underperforming pages against the actual source of truth for the data they display: are the values still accurate and current, or have they drifted out of date since the pages were generated. Look specifically for patterns rather than isolated errors, a systematic staleness affecting an entire data category, a source feed that stopped updating on schedule, or a data field that used to populate correctly and now returns null or default values across many pages. A data-quality problem tends to correlate with a specific data source, update cycle, or field, cutting across the page set in a pattern tied to when or how that data was last refreshed, rather than correlating with any particular structural aspect of the page layout itself.
Step two: audit the template and rendering output independently
Separately, audit the template’s actual rendered output for structural quality issues that exist independent of whether the underlying data is accurate. This means checking the ratio of unique, substantive content to repeated boilerplate across a sample of pages, whether the page structure gives Google’s crawlers and quality evaluation enough differentiated content to distinguish one page from its near-neighbors, and whether the template’s presentation of the data adds genuine context and interpretation or just restates raw values with minimal added value. A template-quality problem tends to show up as a structural characteristic present across the entire page set regardless of which specific data instance is being displayed, thin content ratio, generic intro paragraphs, minimal differentiation between pages beyond the variable data points themselves.
Segmenting performance by data-source cohort
When a single template pulls from multiple distinct data sources or feeds (common in enterprise programmatic setups that aggregate several upstream systems into one page type), segment ranking and traffic performance by which source cohort each page’s data came from. If pages fed by one specific source show meaningfully worse performance than pages fed by another source, using the identical template, that’s strong evidence the problem is data-quality, tied to that specific source, rather than template-quality, since the template variable is held constant across the comparison. Conversely, if performance decline is uniform across all data-source cohorts regardless of which feed populated the page, that points away from a single data source being the cause and toward either a template-wide structural issue or a broader external factor (an algorithm update affecting the whole pattern) rather than a data problem localized to one feed.
A worked scenario: how the two causes look different over a timeline
Consider a programmatic set of location pages that all rank reasonably well for six months, then start declining. If the cause is data quality, the decline typically has a traceable trigger point tied to when a specific feed stopped updating correctly, a vendor changed their export format, an internal ETL job started silently failing for one data category, and the pages affected will map cleanly onto whichever pages depend on that specific feed, regardless of when each individual page was originally published. If the cause is template quality, there’s often no clean trigger date at all; instead, the decline tends to correlate with a broader change in the competitive or evaluative environment, a core update, a shift in what Google’s quality systems reward, that simply exposed a structural weakness the template had all along but that wasn’t being penalized as heavily before. The practical diagnostic value of this timeline check is that a data problem usually has an identifiable “before this date, the affected pages performed fine” boundary tied to a specific operational event, while a template problem often doesn’t, because the template’s thinness was present from day one and the ranking decline reflects an external reassessment rather than an internal change in what the template was producing.
It’s also worth being explicit about a failure mode in this diagnostic process itself: a mixed-cause decline can produce a false negative on both individual audits if each is run too narrowly. If the template audit only looks at content-to-boilerplate ratio and the data audit only checks for outright staleness, a scenario where the data isn’t stale but has become less differentiated over time (a source that used to provide rich per-entity detail now returning sparser records due to an upstream change) can slip through both checks, since it isn’t stale in the freshness sense and the template hasn’t changed either. Catching this requires checking not just whether data is current, but whether the amount of substantive, differentiating information per record has declined over time, a dimension distinct from both staleness and template structure that’s easy to miss if the two audits are treated as fully separate rather than cross-checked against each other.
Practical implication
Run both audits in parallel rather than sequentially guessing at one cause first. Pull a representative sample of underperforming pages and check them against three things: the current accuracy and freshness of their underlying data versus source of truth, the structural content-to-boilerplate ratio of the rendered page compared to the template’s intended design, and, where multiple data sources feed the same template, whether the decline correlates with a specific source cohort. A decline that correlates with data source and shows measurable staleness or accuracy drift against source of truth points to a data problem, fixable by improving source freshness, validation, and update cadence without necessarily touching the template. A decline that’s uniform across all data sources and correlates instead with structural characteristics of the rendered output, thin unique content ratio, minimal differentiation, points to a template problem, fixable by redesigning the template to add genuine synthesis and differentiation regardless of which data feeds it. Treat the diagnosis as inconclusive, and keep investigating both angles, if the pattern doesn’t cleanly point to one variable over the other; mixed causes (a template that was already borderline, made worse by a specific data source degrading) are common enough that the fix sometimes needs to address both simultaneously.
