Why We're Pruning /events/omr-festival (and Merging It Into Our Events Hub)
by Trivas.ai
|
6 min read
Oct 19, 2026
We run a quarterly content audit across every indexed URL on the site, and /events/omr-festival just failed it. Not failed as in "underperforming." Failed as in: under 10 impressions and zero clicks over three months. That's not a page with a traffic problem. That's a page nobody is finding, clicking, or missing.
So we're pruning it. Here's the actual reasoning, not just the decision.
The Data Behind the Prune Decision
Under 10 impressions across 90 days is statistically meaningless for a standalone indexed URL. You can't optimize a page based on that kind of volume. You can't even tell if the few impressions it got were relevant queries or noise. Zero clicks on top of that means the page has never once earned a visit from search. It's been live, indexed, and completely invisible in any way that matters.
Here's the part most teams miss: a page like this doesn't just sit there quietly failing. It drags.
Crawl budget isn't infinite, even for a site our size. Every thin, low-signal page Google crawls is a page it's not spending that budget crawling something that actually converts. And there's a quality-dilution effect too. When a cluster of pages under the same subfolder (in this case /events) consistently shows thin content and no engagement, Google's assessment of the whole cluster gets dinged. One weak page in a folder of ten strong ones is a rounding error. One weak page in a folder of six is a quarter of your signal.
To be clear: this isn't a "we lost rankings and need to fix it" story. There was no ranking to lose. This is sitewide hygiene. We're removing a page that contributes nothing and quietly costs something.
What's Actually On the Page Right Now
Before pruning anything, we inventoried what's actually sitting on /events/omr-festival. It breaks down into two buckets.
First, the time-bound stuff: this year's specific event dates, the location details for that edition, and a line about our booth number and attendance. All of that is dead weight the moment the event wraps. Nobody searches for last year's booth number.
Second, the evergreen stuff: a description of what OMR Festival actually is, who tends to attend (DTC and ecommerce marketing folks, mostly), and why a brand in our space would care about showing up there at all. That part doesn't expire. It's just generic enough that it doesn't need its own URL to say it.
The split matters because it tells us exactly what to keep. The evergreen description earns a spot somewhere. The logistics don't earn anything, they just need to be dropped.
Merge Target: Consolidating Into the /events Pillar
The obvious home for what's worth keeping is the events hub itself. That page already aggregates every event we show up to or mention, so folding OMR Festival in there isn't a stretch, it's just finishing a job the hub was already supposed to do.
Format-wise, OMR Festival doesn't need a dedicated page. It needs a card: name, category, one line on why it's relevant to an ecommerce or DTC audience. That's it. No separate URL, no standalone content, no SEO equity we have to try to build from scratch on a page nobody searches for.
Look at how Deliver Europe 2026, Shoptalk Europe 2026, and Multichannel Day are currently structured on the hub. Those events have enough going on, sessions, speakers, a reason for someone to actually land on a dedicated page, to justify their own URLs. OMR Festival never had that volume of content to begin with. Forcing it into the same format as those three was the real mistake, not the merge.
301 Redirect vs Noindex: Picking the Right Mechanism
Default move here: a 301 redirect from /events/omr-festival straight to /events. Not noindex. Not a 404.
Noindex-only makes sense when an event is permanently gone and redirecting would mislead someone who clicks through expecting event info. That's not the case here. OMR Festival is an ongoing event, we just don't need a standalone page for it anymore. A 301 sends anyone with an old bookmark or a stray backlink somewhere actually useful instead of a wall.
It also means any minimal link equity the page accumulated doesn't just evaporate. A 404 or a noindex dead-end throws that away. A 301 passes it forward to the page that's actually doing the work now.
Implementation Checklist
Before the redirect goes live, a few things need to happen in order, not after the fact:
Pull /events/omr-festival from the XML sitemap and strip it from internal nav or footer links. Leaving it referenced while redirecting it just creates confusing crawl signals.
Add the 301 at the server or CDN level, then confirm it with a live curl or header check. You want a single hop, not a redirect chain. Multiple hops slow crawling and occasionally confuse Google about which URL to actually index.
Update the /events pillar page copy to include the merged OMR Festival entry before the redirect ships. This is the step teams skip, and it's the one that actually matters: if the redirect goes live before the content is added to the hub, you've got a gap where the information just doesn't exist anywhere on the site.
Sequence matters more than speed here. Ship the content first, redirect second.
Monitoring After the Prune
Once the redirect's live, check Search Console for four to six weeks. Two things to watch:
Crawl errors or lingering impressions on the old URL. Some residual impressions are normal immediately after a redirect as Google re-processes the URL, but they should taper off, not persist.
The /events pillar's own impressions and clicks. If those drop after the merge, that's not a clean consolidation, that's a sign something about the new content or structure backfired. A good merge should leave the hub flat or slightly up, never down.
Last step: re-run the same sitewide quality assessment that flagged this page in the first place. If the drag signal on the /events folder doesn't clear, the prune didn't do its job and something else in that folder needs a look.
Next Steps for the Content Team
This isn't a one-off cleanup. The same audit framework needs to run against every other event page sitting at single-digit impressions before they pile up into a bigger problem. Catching these quarterly is a lot cheaper than catching them annually.
Going forward, /events should be the default home for any event mention. Spinning up a new URL per event only makes sense when there's genuinely enough content, speakers, sessions, detailed takeaways, to justify a dedicated page. Most events don't clear that bar. OMR Festival didn't.
One more thing worth looping in: whoever owns the /trial and talk-to-a-founder CTAs should check that the consolidated /events page still points readers toward a clear next step. A merged page is only a win if it still converts, not just if it's tidier.
If you're curious how we run these audits or want a closer look at how we think about site structure generally, our resources section has more breakdowns like this one worth poking around in.
Content author and contributor at Trivas.ai, sharing insights on e-commerce analytics, business intelligence, and data-driven strategies to help businesses grow.
Continue Reading
explore more insights
Content Pruning Plan: Feature Engineering for Improved Accuracy
3 min read
Advanced Cohort Analysis Methodologies
3 min read
AI Wingman: Ecommerce Analytics That Tells You What To Do Next