.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiHere's the data: /resources/data-dictionary/total-customers pulled under 10 impressions and exactly zero clicks over the last three months. That's not a slow page. That's a page nobody is finding, and if they do find it, nobody's clicking through to it.
A standalone glossary entry for one metric, sitting at a thin word count, starts to look a lot like the main data dictionary index and every other metric page around it. Google sees near-duplicate structure: short definition, a formula, maybe a sentence of context, repeat across a dozen URLs. That pattern doesn't read as "comprehensive resource section." It reads as thin content, multiplied.
And thin pages don't just sit there quietly failing. They drag down how Google evaluates the whole /resources/data-dictionary directory. Crawl budget gets spent on pages with no demand, and quality signals for the section average down instead of up.
So this isn't a page getting neglected. It's a page getting folded into something denser, on purpose.
None of the actual definition is wrong or going away. Total customers means unique buyers who completed at least one order in a given period, deduplicated across order IDs. Simple enough on paper.
The variants are worth keeping too. New vs. returning customer counts matter for anyone trying to separate acquisition from retention. And platform handling differs in ways that trip people up: Shopify's guest checkout can create separate customer records for the same person, while Amazon rolls buyers up under marketplace buyer IDs that don't always match how you'd count them internally.
The one nuance that genuinely needs to survive the merge: total customers alone is a vanity metric. A brand with 50,000 total customers and a 12% repeat rate is in a very different spot than one with 20,000 customers and a 45% repeat rate. The number only means something once it's paired with LTV or repeat purchase rate. That's the sentence that should carry over word for word, because it's the part people actually need.
None of this gets deleted. It gets relocated, with better company around it.
The receiving page is /resources/data-dictionary, and the plan is to stop treating each metric like its own island.
Instead of one URL per term, customer-related metrics get grouped into a single comprehensive section: total customers, new customers, returning customers, CAC, LTV, all living together with shared context. A reader looking up total customers is, almost always, also trying to figure out CAC or repeat purchase rate five minutes later. Right now they'd have to find a separate thin page for each one. That's bad architecture dressed up as organization.
Grouping related terms gives each one more topical weight. A definition sitting next to its neighbors reads as part of a system, not a one-off flashcard. And it keeps readers from bouncing immediately after getting their answer, because the next relevant term is right there instead of a search query away.
The pillar should cross-link aggressively between grouped metrics. Someone reading about total customers should land naturally on repeat purchase rate or CAC without leaving the page. That's the whole point of consolidation: fewer entry points, more depth per entry point.
The move here is a 301 redirect from /resources/data-dictionary/total-customers to the relevant section of the consolidated pillar page. The content isn't disappearing, it's merging, so a redirect is the honest technical signal to send.
A 301 also passes along whatever residual link equity this URL has accumulated, even though organic demand is close to nonexistent. No reason to waste it.
Noindex is the fallback, not the default. If the merged content can't live at a stable, linkable anchor on the pillar page (say, the section structure changes later and the anchor breaks), noindexing the old URL is better than leaving a redirect pointing at nothing useful. But that's a backup plan, not the first move.
This should happen before the next crawl cycle. Every cycle this page stays live as a standalone, thin URL is another data point counting against sitewide quality in Search Console.
Before pulling the trigger, a few checks:
/resources/data-dictionary children for the same impressions-and-clicks pattern. If five other metric pages are sitting at the same near-zero numbers, batch them into one consolidation pass instead of doing this one-off and repeating the whole process next month.Treat this page as the template. Whatever process gets applied to total-customers should get applied, on a recurring basis, to every other thin metric page sitting in the same directory with the same impressions-and-clicks profile.
A quarterly audit makes sense here: pull impressions and clicks for every /resources/data-dictionary child page, flag anything under threshold, and batch the prunes together instead of fixing them one at a time as someone happens to notice.
Worth remembering who actually reads these definitions. It's data analysts and marketing leads pulling terminology for a reporting deck, not casual browsers skimming for fun. That audience wants depth and context in one place, not twenty scattered stubs they have to piece together. Fewer, denser pages serve that reader better than a long tail of thin ones, and the kind of reporting workflows these people build in BI and reporting tools depend on consistent, well-grounded definitions, not fragments.
No reader-facing CTA belongs in a page like this one. This is an internal action record documenting a content decision, not a published article trying to convert anyone. If you're building out your own data dictionary or reporting glossary and want a second set of eyes on what's worth keeping standalone versus consolidating, our guides and reports library has more on structuring resource sections that actually hold up over time.
explore more insights
3 min read
3 min read
3 min read