WHAT SHOULD YOU REMOVE FROM a WEBSITE BEFORE ADDING ANYTHING NEW, AND HOW a WEBFLOW AGENCY UK TEAMS TRUST APPROACHES IT
The page everyone wants to add is never the problem. The forty pages nobody has looked at since 2019 are the problem, and they are still there when the new build starts, because nobody has the authority to say "delete this" and make it stick. The real obstacle to removal at a company of fifty people or more isn't data. It's governance. This is how to decide what goes, who gets to decide it, and where the universal advice to "remove what has no traffic" is dangerously wrong.
TL;DR
Audit first, but don't trust it blindly - see webflow development agency for how we scope that work.
Sort pages into five buckets, not two: keep, improve, consolidate, redirect, delete.
"No traffic" does not mean "no value" - compliance, paid-ad, backlink and support-deflecting pages break that rule constantly.
Removal is a governance problem before it's a technical one: name who approves what, before the audit surfaces a fight.
Stagger large removals over weeks, not days, so you can actually read what helped.
Document every decision with its evidence, because someone will ask why in six months and nobody will remember.
Why Removal Has to Come Before Addition
Adding to a site that hasn't been cleared out means building new structure on top of old decisions nobody re-examined. The new navigation inherits the old page hierarchy. The new CMS gets a straight import of old content types, including ones that exist because someone needed them once, for a campaign that ended three years ago.
Redirect mapping becomes a guessing exercise during launch week instead of a decision made with time to check it. None of this is really about search engines - it's about not repeating old commitments for another three years. Teams scoping a web design and development project usually discover the removal question only once the sitemap draft is already late.
What the Audit Actually Has to Prove
This is the step most webflow agency uk engagements start with, before any design conversation happens. The audit's one job is to give you evidence a removal decision can stand on when someone questions it later. That means pulling four things before anyone touches delete: analytics going back far enough to smooth seasonal noise, Search Console data for pages with impressions but no clicks, backlink data regardless of current traffic, and a technical crawl that separates broken from merely old.
Old is not the same problem as broken, and treating them the same is how good reference content gets deleted alongside genuinely dead pages.
When the Data Itself Can't Be Trusted
If analytics has been broken, filtered wrong, or missing attribution for any stretch of time, the audit is only as good as that data. We've seen companies make removal calls off a GA4 property that had been double-counting internal traffic for over a year.
If you don't trust your numbers, fix the measurement before you use it to delete anything. At minimum, flag every low-traffic page as "unverified" rather than "confirmed dead."
Sort Into Five Buckets, Not Two
The temptation in a cleanup project is "keep or delete," because it's fast. It's also how you lose things you didn't mean to lose.
Keep - doing its job, leave it alone even with modest traffic.
Improve - right content, dated execution: old design, thin copy, no conversion path.
Consolidate - two pages answering the same intent, merged into one.
Redirect - value sits in the URL (backlinks, bookmarks, brand recall), not the content.
Delete - neither the URL nor the content has remaining value; a 410 is honest.
The mistake we see most often is skipping straight to delete-or-keep and missing consolidate entirely. Two FAQ pages answering the same question from different campaigns get left standing because nobody wants to be the one who removes either. Six months later there are three.
Where "Remove What Has No Traffic" Stops Being True
This is the most repeated line in content auditing, and it fails often enough to treat it as a hypothesis, not a rule.
It fails for pages carrying a regulatory or compliance function - a privacy notice nobody reads still needs to exist, and UK retention rules often mean keeping superseded versions on record rather than deleting them outright. It fails for paid-campaign landing pages, where organic traffic reads as zero but the page does real commercial work every time a campaign runs. It fails for pages with backlinks from industry publications, where the page itself gets little direct traffic but props up domain authority or a referral relationship someone actually cares about. And it fails for the quiet workhorse pages - spec sheets, troubleshooting guides, edge-case FAQs - that show low traffic and high bounce rate but exist specifically to stop a support ticket or a lost sale before it happens.
You won't see that value in a GA4 report. You'll see it in a reduced support queue, which nobody is cross-referencing against the content audit. This is the point where sales pushes back on marketing's spreadsheet, and sales is often right - a page with zero organic sessions might be the exact page a salesperson sends every third email, because it closes objections.
Separate Old From Broken Before You Touch Either
These are two diagnoses with two different fixes, and conflating them is how functional old pages get deleted while genuinely broken ones stay live because "they've always been like that."
Broken means the page 404s, the layout collapses on mobile, a form doesn't submit, or a script error blocks rendering - fix it or remove it, full stop. Old means the content is accurate and the page loads fine, but the design and voice are dated. Old pages are improve candidates, not delete candidates, unless the information itself is also now wrong.
The financial case for dealing with this now rather than deferring it again: mid-market companies that ignore website technical debt for three to five years often end up paying one and a half to two times more to fix or replace the stack than if they'd worked from a deliberate roadmap, according to Nextwave Services. Cleanup now is cheaper than cleanup after another redesign cycle has compounded the mess. Teams rebuilding on Webflow through webflow development tend to find this debt concentrated in the pages nobody has opened in years.
Managing SEO Risk During Removal, Rather Than Avoiding It
Three response options exist for a page coming down, and choosing between them is a decision, not a default.
A 301 redirect passes existing authority to a live destination, and is right when there's a genuinely relevant page to send people to. The common failure isn't technical, it's lazy mapping - sending everything to the homepage because nobody had time to find the right destination, which protects almost none of the original value. The exact mechanics of which status code to use are worth checking against the HTTP status code reference rather than guessing.
A 410 response tells search engines the page is gone and not coming back, and is the honest choice when there's truly no equivalent content left. It clears the URL from the index faster than a 404, which leaves ambiguity about whether the absence is temporary. If you need to speed that process along, Google's own Search Console removal tool handles the request directly rather than waiting on a recrawl.
Canonical tags are the right tool when you're not removing anything, just telling search engines which of several similar URLs should rank - useful during consolidation when both pages stay live for separate reasons.
The costliest failure is marking a page "deleted" in a project tracker and never implementing the redirect. Nobody notices until months later when organic traffic to a whole content category has dropped and stayed down, by which point the backlink equity is gone.
Stagger large batches. Removing fifty pages in one week makes it almost impossible to tell which removal helped and which hurt, and concentrates ranking volatility into a sharp dip rather than letting it absorb gradually. Spreading removals over several weeks costs a tidier project timeline but buys a readable signal.
Naming Who Actually Gets to Say Yes
Decide this before the audit starts, not after it surfaces a disagreement. Four roles need naming, not assuming: someone owns the final call for each content area, usually whoever owns the department's goals rather than whoever built the page. Someone owns technical execution and signs off that redirects are actually live, not just scheduled. Someone from sales or customer-facing teams sits in the room specifically because they see dependencies analytics can't show - campaign landing pages, email-linked content, a page quoted in a proposal template fifty times a month. And legal or compliance flags retention requirements before deletion, not after.
Political gatekeeping - a department head blocking removal not on evidence but because they built the page - is a real dynamic in larger organisations, and no framework resolves it cleanly. What helps is documentation: if the data shows no traffic, no backlinks, no stated business function, and the only objection is "I don't want to," that objection gets named as what it is, and leadership needs to be willing to override it.
The Hidden Cost of Keeping Everything
Keeping a page is never free, even when deleting it looks like more effort than it's worth. Every page kept is a page someone maintains, a page that competes for crawl budget on larger sites, a page that dilutes internal link equity by adding one more node to the graph, and a page that adds to the cognitive load of anyone mapping the site during the next redesign.
On a twenty-page site this cost is trivial. On a site with several hundred or several thousand pages, the accumulated weight of unmaintained content genuinely drags on technical performance and organisational clarity - it's why large-site audits take weeks, not hours, and why nobody can say with confidence what half the site is for.
This cuts the other way too. If getting three departments to agree on deleting one page costs more in meeting time than the page costs in server space and marginal crawl budget, leaving it might be the rational choice. Not every page is worth the fight. Save the stakeholder capital for pages with real traffic, real backlinks, or real ranking value at stake - the evidence base teams reference when choosing a webflow design agency partner to run this work with them.
Sequencing Cleanup Against a Redesign or Migration
Audit and classify before scoping the new build. Execute removal in parallel with the build, not after launch, and that includes planning your redirects as a real deliverable rather than a last-minute fix - the kind of planning a webflow design agency london team would set up before touching a single live campaign page.
If cleanup happens entirely post-launch, you've already paid to design, build and migrate content you were going to delete anyway, and redirect mapping gets rushed in the final week when everyone just wants to ship. If it happens too far in advance with no build scheduled, momentum dies and half the agreed removals never get executed because nobody owns the follow-through once the audit report is filed away. Platform-specific implementation details, like how Webflow handles redirect rules during a rebuild, are covered in the Webflow redirect documentation.
Urgency can legitimately override this order. Migrating off a platform that's being sunset, or a system actively failing, may not leave runway for a full audit first. In that case, run a lightweight pass covering only what can't be fixed cheaply later - compliance content and anything with significant backlinks - and schedule the fuller audit as a near-term follow-up rather than skipping it.
Measuring Whether Removal Actually Worked
Watch three signals over weeks, not days: Search Console impressions and clicks for removed URLs and their redirect targets, to confirm the redirect passes value rather than quietly failing; overall crawl stats, to see whether crawl frequency shifts toward pages you kept; and conversion or engagement on consolidated pages, to check merging didn't dilute intent-matching for either original audience.
Be honest about what won't show up this way. Brand equity, indirect revenue from pages that feed offline sales conversations, and risk reduction from removing outdated content don't appear cleanly in analytics. If a salesperson says a page helps close deals, GA was never going to validate or refute that - treating the absence of digital proof as proof of absence is a mistake in the other direction from the one most audits warn against.
Three Approaches to Deciding What Goes, Compared
Documenting the Decision, Not Just the Outcome
Record why, not just what, for every removal - six months from now someone will ask and nobody will remember the reasoning. A simple record per page - traffic and backlink status at review, who approved it, which method was used, where it redirects - turns cleanup into something future teams can actually audit again rather than a one-off event.
It also protects you. If a removal turns out wrong, the record shows it was a considered decision based on the evidence available at the time, not an oversight.
If it was wrong, reinstating is possible but not free - bringing a page back after search engines have processed a 410 means re-earning ranking signal rather than simply restoring it. Catch that in the first few weeks, while the cause is still obviously connected, rather than a year later when it's hard to trace. Portfolio work referenced through client project examples shows how differently this plays out when the documentation exists versus when it doesn't.
What Should Never Be on the Table
Hold a short list immovable regardless of what the traffic data says: anything with an active legal or regulatory retention requirement, current terms and privacy content, any live landing destination for a running ad campaign, and anything sales or support can name a specific, current use for. Accessibility obligations sit here too - the WCAG content guidelines are the reference point when you're deciding whether consolidating or removing a page could affect compliance for regulated or public-facing content. Everything else goes through the framework above. Those four don't, and no traffic number should override that.
Final Verdict
If your site is under fifty pages, the stakes are low enough to run this quickly: audit, classify, remove, redirect, done inside a fortnight. If you're managing several hundred pages across departments that don't talk to each other, the governance step matters more than the audit itself - name who approves what before you find out the hard way, mid-project. The work a webflow agency uk teams bring in usually starts here, not at the design stage.
Either way, the sequencing question - before the build, during it, or after - decides more than the content classification does. A webflow design agency london teams already use for this groundwork can help you sort the two apart before anything gets redesigned, and if you'd rather talk it through directly, get in touch.
FAQs
Q: Should we delete our low-traffic pages or redirect them?
A: It depends on whether the URL carries value independent of the content. If it has backlinks, brand recognition, or a returning-visitor habit, redirect it to something relevant rather than deleting outright. If neither the URL nor the content has remaining value, a 410 is the honest response. Check backlinks before deciding either way.
Q: How do we know if a page with no traffic is actually valuable?
A: Traffic alone won't tell you. Check Search Console for impressions without clicks, check backlinks regardless of current sessions, and ask sales and support whether they reference the page directly. A page can show zero organic sessions and still close deals or deflect support tickets every week.
Q: What happens to our SEO when we remove a page that ranks?
A: If you redirect it properly to a genuinely relevant destination, most of its ranking signal transfers over time. If you delete it without a redirect, or redirect it to an unrelated page like the homepage, that value is largely lost. Stagger large removals so you can actually see which caused any drop.
0 comments
Log in to leave a comment.
Be the first to comment.