A Website Redesign Should Start With a Deletion List

Most website redesigns begin with a wish list. Stakeholders request new landing pages, richer animation, another integration, and a larger navigation menu before anyone examines what the current site is carrying. The result can be a faster-looking version of the same clutter: duplicate messages, abandoned campaign pages, obsolete plugins, and features nobody owns. A deletion list changes the order of operations. It identifies what should be removed, merged, archived, or retired before the new structure is designed. This is not minimalism for its own sake. It is a practical way to reduce scope, sharpen the site’s purpose, and avoid rebuilding old decisions at new-project prices.

Start with an inventory, not opinions

You cannot decide what to remove until you know what exists. Crawl the public site and combine that list with pages hidden from navigation, downloadable files, forms, redirects, custom post types, integrations, plugins, and recurring content workflows. Include assets that live outside the CMS but depend on the website, such as a newsletter signup webhook or a campaign subdomain.

Give each item an owner and a current purpose. A simple spreadsheet can track URL, content type, last meaningful update, traffic, conversions, backlinks, maintenance cost, and proposed action. The inventory often reveals surprises: three pages describing the same service, a form delivering to a former employee, or a plugin retained for a campaign that ended two years ago.

Use evidence without letting analytics make the decision

Low traffic is a useful signal, not an automatic deletion rule. A privacy policy may receive few visits but still be required. A specialized service page might support a small number of valuable sales conversations. Conversely, a high-traffic article can attract the wrong audience and contribute nothing to the business.

Evaluate every item across four questions: Does it serve a current user need? Does it support a current business goal? Does it earn meaningful search visibility or links? Is somebody responsible for keeping it accurate? Content that fails all four is a strong removal candidate. Content that passes only one may need merging or a clearer role. Record the reasoning so stakeholders can challenge the evidence rather than defend pages from memory.

Sort everything into keep, improve, merge, or remove

A binary keep-or-delete exercise creates unnecessary conflict. Four outcomes give the team better options. Keep pages that are accurate and effective. Improve pages with a valid purpose but weak execution. Merge overlapping pages so visitors and search engines get one authoritative answer. Remove material that no longer deserves a place in the system.

• Keep a well-performing service page with a clear owner.
• Improve an important pricing page whose explanation causes support questions.
• Merge several thin location or capability pages that repeat the same information.
• Remove expired event pages, dead integrations, stale team bios, and unused campaign forms.

Apply the same model to functionality. A rarely used calculator with high maintenance cost may be a worse investment than a plain explanatory page. An old plugin that supplies one decorative widget might be replaced with a small native component.

Plan redirects and preservation before deleting

Deletion is a publishing operation, not an act of erasing files. For every removed URL, decide whether there is a genuinely relevant destination. Use a permanent redirect when another page satisfies the same intent. Return a clear not-found or gone response when no replacement exists. Redirecting every deleted page to the homepage confuses visitors and weakens the meaning of the redirect.

Preserve business records, legal material, and useful source files outside the public site when required. Export form submissions before retiring a form plugin. Capture copy that may be needed for compliance. Update internal links, campaign URLs, navigation, sitemaps, and external profiles. This work belongs in the redesign scope because a clean launch depends on it.

Let the deletion list shape design and scope

Once removals and merges are agreed, the new information architecture becomes easier to design. Fewer competing service pages can produce a clearer navigation. Retiring unsupported features reduces template variants. Removing obsolete fields simplifies migration and gives editors a more focused admin experience. The team can spend its budget on the journeys that remain instead of reproducing every historical exception.

The list should also influence estimates. Each deleted content type saves design, development, migration, testing, training, and future maintenance effort. Make those savings visible. Stakeholders are more willing to retire a weak feature when they can see the stronger work that its removal funds.

Turn removal into an ongoing governance habit

A redesign creates a deadline, but clutter returns if publishing has no lifecycle. Assign owners to important sections, add review dates for time-sensitive pages, and define what happens when a campaign ends. New plugins and integrations should have a business owner, a review date, and an exit plan. Content requests should identify which user need they serve and whether an existing page can be improved instead.

Before wireframes are approved, hold a deletion review with content, marketing, operations, development, and whoever handles search performance. Confirm the keep, improve, merge, and remove decisions, along with redirects and archives. The best redesign is not the one that launches with the most new material. It is the one that makes the useful parts easier to find, easier to trust, and cheaper to maintain.

Photo by Pixabay on Pexels.