.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiUnder 10 impressions and zero clicks over a 3-month window. That's the entire performance record for the URL /https://www.trivas.ai/, and it's why this page landed on the pruning list in the first place.
The numbers are blunt: fewer than 10 impressions, zero clicks, three months of data. No seasonal bump, no slow build, nothing.
That's not a "low competition" problem. Low competition still shows some query matching, some impressions trickling in from long-tail searches. Near-zero volume like this means the URL isn't matching any real search demand at all. Google isn't choosing to rank something else over it. It's not finding a reason to surface it, period.
Here's the part teams miss: a page like /https://www.trivas.ai/ isn't a neutral, do-nothing line item sitting quietly in the background. Thin or orphaned URLs eat into crawl budget and feed into the site-wide quality signals search engines use when deciding how much to trust the rest of your domain. One dead page rarely tanks a site. A pile of them does.
Search engines don't grade pages one at a time in a vacuum. They look at patterns across a domain: how many URLs are thin, how many duplicate each other, how many haven't been touched in years. That pattern shapes how often your genuinely useful pages get crawled and how fast fresh content gets indexed.
Let a handful of low-value URLs pile up, and indexing speed slows down across the board. New product pages, updated guides, the stuff you actually want ranking, all of it waits longer in line because crawlers are spending cycles on pages that go nowhere.
The URL pattern here makes it worse. /https://www.trivas.ai/ is a slash-prefixed full URL path, essentially a duplicate of the root domain wearing a disguise. That kind of malformed structure can confuse canonicalization signals: search engines may not be sure whether this is a distinct page or an accidental mirror of the homepage, and that ambiguity itself is a quality signal working against you. If you're auditing your own URL inventory for the first time, the getting started resources walk through how to spot this kind of structural noise before it spreads.
If /https://www.trivas.ai/ is functionally a duplicate of the homepage, the fix is straightforward: merge whatever unique value it has into the real homepage (or a core solutions hub, if the content leans that direction) and 301 redirect the URL into it.
A 301 isn't just cleanup. It passes along any residual link equity or historical ranking signal instead of letting it evaporate. If anything ever linked to that malformed URL, even by accident, a redirect keeps that value flowing somewhere useful.
Before you merge, check three things:
For a near-zero-traffic page like this one, the answer to all three is usually no. But check anyway. It takes five minutes and saves you from losing something you didn't know was there.
Once the redirect's live, go back and update every internal link and sitemap reference pointing at the old URL. A 301 that's still being linked to internally sends mixed signals, you're telling users and crawlers "this page still exists" while simultaneously telling them to leave it. Clean that up.
Redirecting isn't always the right move. If a URL serves some required technical or legal function, like a tracking endpoint, a system-generated path, or a page a third-party integration depends on, but it has no business competing for search visibility, noindex is the better call.
The tradeoff is simple. A 301 kills the URL and sends everything to a new destination. A noindex tag keeps the URL live and functional for whatever users or systems still need it, while telling search engines to leave it out of the index entirely. You get to keep the plumbing without it dragging down your search quality profile.
What you shouldn't do is leave a page like this indexable with no clear search intent behind it. Letting it sit there, technically crawlable, matching no real query, just keeps contributing to the same sitewide low-quality signal that got it flagged in the first place. Indecision is worse than either option.
Run it through a short checklist:
If the answer to the first two is no and the third doesn't apply, 301-and-merge is the default. That's true for most redundant or thin URLs, and it's almost certainly true here.
Noindex only makes sense when a redirect isn't technically appropriate, for example when the URL is a malformed duplicate of the root domain itself and redirecting it could create a loop or conflict with existing homepage canonicalization. In that specific edge case, noindex (or in some setups, a canonical tag pointing back to the root) is cleaner than forcing a redirect into a URL structure issue you'd rather just resolve at the source.
For /https://www.trivas.ai/ specifically, given the near-duplicate pattern and the total absence of unique value, a 301 back to the homepage is the more defensible path. It resolves both the traffic non-issue and the canonicalization ambiguity in one move.
Once you've picked a direction, the execution is mechanical:
/https://www.trivas.ai/ to the destination page.Give it four to six weeks after that. You're watching for two things: confirmation that the redirect's being picked up (check the Page Indexing report), and confirmation that no new impressions are showing up on the pruned URL, which would suggest something's still pointing traffic or crawlers at it.
Don't treat this as a one-time fix. Run the same pruning review quarterly against your full URL inventory. Low-value pages don't announce themselves, they accumulate quietly from old campaigns, abandoned tests, and CMS quirks, and catching them early is a lot cheaper than cleaning up a backlog of fifty of them two years from now.
None of this matters if the page absorbing the redirect isn't actually good. Pruning a weak URL into an equally thin destination just relocates the problem. The homepage or hub page on the receiving end needs to be genuinely comprehensive and well-optimized for the terms it's meant to own, or you've done cleanup without doing improvement.
Once this one's handled, do the same scan across your blog index and other high-volume content areas. Old posts and orphaned landing pages are usually where the next batch of zero-impression URLs are hiding.
If you're not sure where to start digging through your own page-level performance, that's a diagnostics problem, not a guessing one. Worth poking around how Trivas approaches analytics for exactly this kind of question, or just subscribing to keep tabs on future posts like this one. And if something about the pruning process itself still feels unclear, the FAQs page covers a few of the more common sticking points.
explore more insights
3 min read
3 min read
3 min read