.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiThis is an internal audit post, written for our own content team (and anyone curious how we handle page-level pruning decisions). The page in question: /resources/blog-insights/trivas-pricing. Here's the call and the plan.
The numbers don't leave much room for debate. Under 10 impressions and zero clicks over the last three months. Not a slow page, a dead one.
A page with that little traffic isn't neutral. It's not just sitting there doing no harm. Thin, low-traffic pages like this one create duplicate content risk against the real pricing page, and they dilute the overall quality signal Google reads across the site. Every near-empty page is one more thing dragging down the average.
This isn't an algorithm flag. No automated tool put trivas pricing on a kill list. A human reviewer went through the blog inventory, saw a page with pricing claims that overlap with /pricing, checked the performance data, and marked it for consolidation. That's the Manual bucket: a person made the call, with context an algorithm doesn't have.
The old trivas-pricing post covers plan tiers, a feature breakdown by tier, and a couple of specific pricing figures. Standard blog-post-as-pricing-page stuff, the kind of thing that gets written early on and then never revisited.
Some of it is stale. The pricing figures in particular need a hard look, since anything dated against the current /pricing page risks showing two different numbers for the same plan. That's a trust problem, not just an SEO one. If a reader finds the blog post first and sees a number that doesn't match the live pricing page, that's a bad first impression before they've even talked to anyone.
Most of the feature-breakdown content is duplicated almost verbatim from /pricing already, just reworded slightly. That doesn't need to survive the merge. No reason to carry forward a weaker copy of something that already exists.
There is one thing worth saving: a short FAQ-style section comparing plan options for Amazon sellers specifically. That's a genuinely different angle than what's on the general pricing page, and it's the one piece of this post actually worth preserving before the rest gets retired.
General plan and tier content consolidates into /pricing. That's the pillar, and it's where this kind of content belongs by default.
The Amazon-specific material is the exception. Rather than force it into the general pillar where it'll just get buried under non-Amazon context, it goes to /pricing/amazon instead. That page exists for exactly this reason: pricing questions that only make sense for sellers running Amazon alongside or instead of Shopify.
The rule for the merge itself is simple: only move sections that add something the pillar page doesn't already say. The restated marketing copy, the generic "why choose Trivas" paragraphs, none of that needs to move. It's filler, and merging filler just makes the destination page worse. The Amazon FAQ moves. The stale pricing figures get checked against current numbers before anything goes live, and if they're wrong, they get fixed, not copied over as-is.
Once the content is placed, /resources/blog-insights/trivas-pricing gets a 301 redirect. Target is /pricing for most of the traffic intent, or /pricing/amazon if it turns out the Amazon FAQ ends up being the bulk of what's actually unique on the page. Worth deciding this before the redirect goes live, not after.
Then the cleanup pass: the blog index needs the listing removed so it stops surfacing a page that no longer exists as a destination. Same for any nav menus or sitemap entries still pointing at the old slug. Easy to forget the sitemap specifically, since it doesn't break visibly if it's wrong, it just confuses crawlers.
Last step before anything goes live: search the site for internal links still pointing at the old URL. Old blog posts, footer links, anything. Repoint every one of them directly at the new destination rather than letting them hop through the redirect. A redirect chain from an internal link is a sign nobody actually checked the work.
If someone on the team wants the URL kept alive for reasons outside search (say, it's linked from an old email campaign that's still running), apply noindex, follow instead of a 301. That keeps the page reachable for anyone with the direct link, while telling search engines not to index it.
But that's a narrow case, and it needs documentation if it happens. The only legitimate reason to noindex instead of redirect is a non-search use for the URL. If there's no such use, noindex is the wrong tool. It leaves a thin page sitting on the site collecting nothing.
Default recommendation here is 301, not noindex. This page has no unique traffic worth protecting a URL for. Zero clicks in three months doesn't earn an exception.
Before flipping the redirect live, confirm the destination page actually contains the merged content. Sounds obvious, but it's the step that gets skipped most often: the redirect goes live, and the Amazon FAQ never actually made it onto /pricing/amazon. That's a dead end dressed up as a redirect.
Check the status code. It needs to be a real 301, not a 302, and not a redirect that bounces through two or three hops before landing. Chains slow down crawl and dilute whatever link equity the old page had left (which, admittedly, isn't much given the traffic numbers, but still worth doing right).
A week after launch, re-crawl the site. Confirm the old URL is fully out of the index and that nothing internal still links to it. If an orphaned link turns up, fix it then rather than waiting for the next audit cycle to catch it.
Someone needs to own this, with an actual date attached. "Eventually" isn't a plan.
Beyond this one page, it's worth flagging the pattern: sub-10-impression, zero-click pages are a type, not a one-off. Adding a quarterly audit step specifically looking for pages in that bucket means catching the next one before it sits around for a year doing nothing. This one got caught because a reviewer happened to look. The next one shouldn't rely on luck.
Once the merge and redirect are live, log it in the content inventory: what was merged, where, redirect target, date. Future audits move faster when the history is written down instead of rediscovered.
If you want more of this kind of breakdown (what we're changing on the site and why), the blog is where we post it. Worth a subscribe if content audits and pricing-page decisions are your kind of reading.
explore more insights
3 min read
3 min read
3 min read