.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiWe're retiring /resources/data-dictionary/delivery-rate as a standalone page. The content isn't disappearing, it's moving into the main data dictionary pillar, with a 301 redirect left behind to carry over whatever equity the URL still has. Here's the reasoning and the exact steps we're taking.
The numbers made this an easy call. Over the last three months, /resources/data-dictionary/delivery-rate pulled under 10 impressions and exactly zero clicks. Not "low traffic." Basically no traffic.
A page performing that poorly isn't just sitting there harmlessly. Thin pages drag down sitewide quality signals, the kind Google's systems use to judge an entire domain, not just the one URL. When you've got a glossary structure made up of dozens of near-empty leaf pages, each one covering a single term in a few hundred words, you're not building topical authority. You're fragmenting it. All that authority should be consolidating onto one strong pillar page instead of spreading thin across individual stubs.
This isn't a verdict on the original page being badly written. It's a content-health decision. Some terms deserve their own URL because people search for them directly and expect a dedicated answer. "Delivery rate" isn't one of those terms, at least not at the volume we're seeing. It belongs as a section inside a bigger resource, not a page fighting for visibility on its own.
Before anything gets merged, it's worth cataloging exactly what's there so nothing gets lost in the move.
The page defines delivery rate as successful sends divided by total sends, expressed as a percentage. It's framed mainly around email and SMS campaigns, with a secondary mention of marketplace fulfillment contexts where "delivery" means something closer to order delivery rather than message delivery. The formula is straightforward:
Delivery Rate = (Successful Sends / Total Sends) x 100
There's a worked example on the page too: a campaign sending 10,000 emails with 9,750 landing in inboxes works out to a 97.5% delivery rate. That example is simple enough and clear enough that it's worth carrying over word for word into the pillar rather than rewriting it from scratch.
The page also references a rough benchmark range, noting that anything above 95% is generally considered healthy for email, while rates dropping below 90% usually signal a deliverability problem worth investigating (bad list hygiene, spam flags, that kind of thing).
None of this is tied to a specific customer or case study. No brand names, no proprietary data, nothing that needs separate handling or approval before it moves. That makes this one of the cleaner merges on our list, there's no risk of accidentally publishing something that should've stayed private.
The destination is the main data dictionary index page. That page is already the logical hub for metric definitions across the platform, and it's the one page in this whole section that should actually be carrying ranking authority.
The logic here is simple. One comprehensive page covering delivery rate alongside related ecommerce metrics, fulfillment rate, conversion rate, and others, is going to outrank a scattered set of isolated stub pages almost every time. Search engines reward depth and comprehensiveness on a single URL more than they reward a dozen thin pages each covering one adjacent term. Consolidation isn't just cleanup, it's a ranking strategy.
Practically, delivery rate becomes a subsection on the pillar page with its own anchor link, so anyone can still jump straight to it from a table of contents or a direct link, they just won't land on a standalone URL to do it. The formula, the worked example, and the benchmark range all move over as-is.
This also cleans up internal linking going forward. Instead of juggling which specific metric page to link to every time delivery rate comes up in a blog post or help doc, every future reference points to one canonical anchor on the pillar. One URL to maintain, one place for the authority to accumulate.
The mechanics of this are deliberately unglamorous. Four steps, in order:
Step 1: Merge the content. Copy the preserved definition, formula, and worked example into the delivery rate section of the pillar page. No rewriting needed, the existing material already does the job.
Step 2: Set up the 301. Redirect /resources/data-dictionary/delivery-rate to /resources/data-dictionary so anyone hitting the old URL, whether from a bookmark, an old backlink, or a stray internal link we missed, lands on the right page instead of a 404.
Step 3: Clean up internal references. Audit any blog posts, help docs, or sitemap entries still pointing to the old URL and update them to point to the pillar's anchor link instead. Leaving stale internal links pointing at a redirected URL is sloppy and adds unnecessary redirect hops.
Step 4: Resubmit for crawling. Push the updated pillar URL through Search Console so Google picks up the new content and reindexes it with delivery rate now folded in.
This is the same four-step playbook we'll use for any other thin glossary page headed for the same treatment.
Merging isn't always the right move. Sometimes noindex is the better call, and it's worth being clear on when that applies.
If the pillar page is already bloated, or if a given term genuinely doesn't fit its current structure, forcing a merge just creates a messier, harder-to-navigate page. In that situation, noindexing the thin page and pulling it out of internal navigation is still a better outcome than leaving a near-zero-traffic page fully indexed and diluting quality signals.
But noindex is the fallback, not the first choice. A 301 redirect preserves whatever residual link equity the old URL might be carrying, however small. Noindex throws that away. We only reach for it when a clean merge isn't realistic.
And it's not necessarily permanent. If the pillar page eventually grows enough to comfortably absorb a term we'd previously noindexed, that's worth revisiting. Content decisions like this should get reviewed periodically, not locked in forever.
Once the merge goes live, we're watching three things.
First, impressions and clicks on the pillar page for the delivery rate query cluster specifically, tracked over the next three months. If the consolidation worked the way it should, that cluster should show some movement rather than staying flat at zero.
Second, a basic technical check: confirming the 301 resolves cleanly in a single hop, not chained through two or three redirects before landing on the pillar. Redirect chains are an easy thing to overlook and they quietly hurt crawl efficiency.
Third, sitewide signals. As more thin data dictionary pages get folded into the pillar, we expect to see improvements in crawl budget efficiency and average page depth across the site. Fewer orphaned, barely-visited pages should mean Google spends its crawl budget on pages that actually matter.
This delivery rate page is really just the test case. If the merge performs the way we expect, it becomes the template for pruning the rest of the data dictionary's low-traffic entries, one at a time, with the same four-step process.
If you're curious how we think about metric definitions and data structure more broadly, our guides and reports section covers a lot of the same ground in more depth, and our help center is worth a browse too. Feel free to poke around, or subscribe if you'd rather have updates like this land in your inbox instead.
explore more insights
3 min read
3 min read
3 min read