.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiWe're pruning app.trivas.ai/privacy-policy. Here's the diagnostic that got it flagged, and the plan for what replaces it.
The keyword plan doesn't leave much room for debate. Over the last 90 days, app.trivas.ai/privacy-policy pulled fewer than 10 impressions and exactly zero clicks. Not low traffic. No traffic.
Normally a number like that gets filed under "harmless, leave it be." This one doesn't get that treatment. It's flagged as an active drag on sitewide quality assessment, not a neutral dead page sitting quietly in the index.
There's a real difference between the two. A thin page nobody visits is usually just inert, a rounding error in your crawl budget. But when a page is templated, duplicate-feeling, and indexed on a separate subdomain, Google's quality systems don't just ignore it. They factor it into how they assess the domain as a whole. That's the distinction that moves this from "someday" cleanup to "do it this sprint."
Legal pages were never going to rank. Nobody searches "trivas privacy policy" hoping to land on a results page, and that's fine, that's not the job of a privacy policy. The job is disclosure.
The problem is what this specific page looks like to a crawler. It's short. It's templated. The language overlaps heavily with what you'd find on a few hundred other SaaS privacy policies, because most of these pages are built from the same handful of legal boilerplate structures with the names swapped out. On its own, fine. Combined with the fact that it sits on an app subdomain, indexed separately from the marketing domain, it starts contributing to a pattern Google's quality systems don't love: fragmented, low-value content spread across properties that should really be consolidated.
There's also a crawl efficiency angle. When app.trivas.ai and the main marketing domain both have indexed legal pages covering the same ground, crawlers spend cycles figuring out which one matters instead of prioritizing the pages that actually drive organic value. None of that fragmentation does your privacy policy on the marketing domain any favors either, since it's now sharing topical space with a near-duplicate.
The plan is to fold the substantive privacy content, data handling practices, retention windows, subprocessor list, into the Trust Center and make that the single authoritative destination for anything compliance-related.
One consolidated trust page beats three scattered legal fragments, for users and for crawlers. A prospect doing security diligence before a contract doesn't want to hunt across four URLs to piece together how you handle their data. They want one page that answers data handling, retention, subprocessors, and compliance posture in one pass. That's what a trust center is for, and it's a stronger SEO asset too: one well-built, regularly updated page earns more authority than several thin ones competing with each other.
Terms of Use isn't part of this merge. Terms of use covers different ground, usage rights, liability, account terms, so it stays as its own standalone legal page. Only the privacy-specific content gets absorbed into the Trust Center narrative.
This is where the decision gets mechanical, not philosophical. It comes down to one question: does anything outside Trivas actually link to app.trivas.ai/privacy-policy?
If yes, if it's referenced in a partner agreement, a third-party audit, a bookmark some enterprise security team has saved, anything external, the right move is a 301 redirect to /about/trust-center. That preserves whatever link equity exists and keeps anyone who clicks an old link from hitting a dead end.
If no, if this is purely an internal app artifact that users only ever hit via an in-app footer link, noindex is the lower-risk path. Pair the noindex tag with a canonical pointing to the marketing-domain /privacy-policy, so there's no ambiguity about which URL should represent that content in search.
One thing isn't up for debate regardless of which mechanism wins: the privacy disclosure itself has to stay live and accessible. Noindexing a page doesn't mean hiding it from users, it just means asking search engines not to index it. Legal accessibility and search visibility are two separate decisions, and only one of them is on the table here.
Before flipping any switches, here's the actual sequence:
app.trivas.ai/privacy-policy, footer links inside the app, onboarding email templates, signup flow confirmations, and update them to point to the surviving page (Trust Center or the marketing domain privacy policy, depending on context)./privacy-policy stays canonical and fully indexable. That's the version that should carry any legal or compliance search intent, however small it is.Skipping the link audit is the most common way this kind of cleanup backfires. A redirect fixes the URL, but if your onboarding emails still hardcode the old link, you're sending users through an extra hop forever.
Nothing here involves deleting compliance content. It's a consolidation, not a removal. Every disclosure that currently lives on app.trivas.ai/privacy-policy either moves into the Trust Center or already exists on the marketing domain's privacy policy.
In-app users who hit the old link get redirected straight through, no dead link, no "page not found," no missing functionality. If anything, they land somewhere more complete, since the Trust Center covers data handling and subprocessors in more depth than the old standalone page ever did.
This isn't a one-off fix either. It's one page out of a broader pass through low-traffic, low-value URLs across the site, the kind of quiet cleanup that doesn't show up in a changelog but adds up over a quarter.
The plan: merge the substantive content into the Trust Center, apply a 301 or a noindex depending on whether external links exist, and update every internal reference so nothing points at a dead end.
If you're looking for the current source of truth on data handling, retention, or compliance questions, that's the Trust Center going forward, not the app subdomain.
This prune is a small piece of a bigger content quality pass we're running across low-traffic pages. If that kind of behind-the-scenes cleanup is useful to you, it's worth keeping an eye on what else shows up on the blog as we work through the rest of the list.
explore more insights
3 min read
3 min read
3 min read