.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiWe're cleaning house in the resource section, and /resources/data-dictionary/string is first against the wall. Three months of search data: under 10 impressions, zero clicks. Not "low performing." Dead.
This isn't a one-off case. It's part of a broader audit of thin glossary pages that are quietly dragging down the whole /resources/data-dictionary section. Here's the plan for fixing it.
The numbers don't leave much room for debate. Under 10 impressions and zero clicks across a full quarter means nobody is finding this page through search, and the few who stumble on it in the results aren't clicking through.
That's not surprising once you think about what the page actually is: a standalone entry defining the word "string." As in, a basic data type. Nobody is searching "what is a string" and landing on an ecommerce analytics site expecting an answer. There's no standalone search demand for a term this fundamental, full stop.
Here's the part that matters more than the zero clicks, though. A page like this isn't neutral. It's not just sitting there doing nothing. Thin, orphaned glossary entries like /resources/data-dictionary/string actively dilute topical authority for the whole data-dictionary section. Google sees a cluster of near-identical, low-value pages and reads it as a quality signal, a bad one, for the parent directory. Every thin entry we leave live is a small tax on the pages that actually matter.
Pull up the page and there's not much there. A short definition of the string data type, maybe one or two example use cases tied to ecommerce fields like SKU or product title. That's it. No depth, no context on how string fields behave differently from integers or dates inside a reporting pipeline, nothing that would make a reader stick around.
Before we touch anything, we need to account for what's linking to it. Check for internal links pointing at this URL (anything in the broader /resources/data-dictionary section or developer docs), and check whether it's carrying any schema markup that other tooling depends on. Neither should block the move, but both need to be mapped so nothing breaks quietly.
The bigger issue: everything on this page is content a proper glossary table on the pillar would cover better, in less space. A term, a one-line definition, an example field. That's a table row, not a page.
Deleting the page outright is tempting. Don't do it.
A hard delete turns those handful of existing impressions into a 404, which is a worse outcome than doing nothing. A 301 redirect to the pillar page preserves whatever residual link equity the page has accumulated and gives searchers (and crawlers) somewhere useful to land instead of a dead end.
If the merge can't ship right away, noindex is an acceptable stopgap, but treat it as temporary. Set a date, something like 30 days out, to come back and finish the job. Noindex alone doesn't consolidate anything, it just stops the bleeding.
Worth remembering: Google still crawls and evaluates redirected URLs. A 301 doesn't make the old page disappear from the index overnight, it tells Google exactly where the authoritative version lives now. That's the whole point. Consolidating a dozen thin child pages into one strong pillar concentrates ranking signal instead of spreading it thin across pages that individually can't rank for anything.
The destination is /resources/data-dictionary, full stop. Not another child page, not a restructured sub-category. One authoritative glossary page that covers every term in a format people can actually scan.
The format change matters as much as the redirect. Instead of a dedicated page for "string," it becomes a row in a glossary table: term, definition, example field, related data type. That's all "string" ever needed. Readers comparing data types side by side get more value from a table than from clicking through four separate single-term pages anyway.
And string shouldn't travel alone. Integer, boolean, date, these are almost certainly sitting on the same low-traffic profile right now. Pull them into the pillar at the same time. One merge that consolidates four or five prune candidates is a far better use of time than four separate one-off redirects spread across different sprints. If your data dictionary overlaps with anything referenced in the developer docs, make sure the pillar's table stays consistent with how those docs describe field types, so you're not creating two slightly different definitions of the same term across the site.
Here's the actual sequence, in order:
/resources/data-dictionary/string to /resources/data-dictionary./resources/data-dictionary/[metric] page. If one basic-type glossary entry has under 10 impressions, there are probably several more sitting in the same spot, quietly accumulating.That last point is the one teams skip, and it's the one that matters most. One thin page is a rounding error. Ten of them is a structural problem.
Before folding in a batch of terms, check that the pillar page can actually absorb them. That means two things: information architecture (does the table stay scannable with 15 rows instead of 5) and page weight (is the page still fast once it's carrying more content and possibly more embedded schema). A glossary table that turns into an unreadable wall of definitions defeats the purpose.
Set a 90-day check-in on the redirect. Confirm it passed authority the way it should and, more importantly, confirm the pillar page's impressions and rankings for data-dictionary-related queries actually moved. If they didn't, that's a sign the content on the pillar isn't strong enough yet, not a sign the merge was a bad idea.
Keep a running list of other data-dictionary child pages to run through the same under-10-impressions filter. This shouldn't be a one-time cleanup. It's a standing maintenance task, the same way you'd periodically review help center articles for ones nobody reads anymore.
If you're tracking how your own reporting pages perform (or quietly don't), this is the same logic we apply across Trivas dashboards: cut what nobody's using, consolidate what's related, and keep the signal clean. Worth subscribing to our resources if you want more of these audits as we run them.
explore more insights
3 min read
3 min read
3 min read