A website redesign should begin with an inventory of old content, followed by page-by-page decisions to retain, update, merge, replace, or delete it. Consider user tasks, current business needs, content accuracy, search performance, and external references. Low traffic is an observation, not an automatic reason for deletion. A technical document may rarely be found through search yet be used frequently in purchasing reviews or support for existing customers.
Before producing the new homepage and visual design, connect these decisions to complete URLs, selected materials, owners, and new destinations. This preserves useful content while removing duplicate and misleading information, and avoids discovering after launch that customers' bookmarked files, links sent by sales, or old language pages no longer work.
1. Build a Content Inventory Including Pages and Attachments
The inventory should include more than pages reachable through navigation. List PDFs, downloads, images, campaign pages, old language versions, and common external entry points as well. Use CMS exports, sitemaps, crawl results, Search Console, analytics, and server logs to fill gaps. The absence of a URL from one source does not establish that it has never been used.
For each record, retain the complete URL, title, content type, subject, language, applicable version, update date, and person responsible for the facts. Then add search performance, backlinks, sales references, and support uses. Mark inaccessible data as not obtained, rather than zero. If business staff say a resource is “still used,” record its purpose and verifiable basis as well.
Pay particular attention to relationships between files and pages. A series manual may serve multiple models, so removing one product page does not mean the whole file can be deleted. The inventory should help the next person identify the original item, rather than merely show a string of paths.
Completion check: Pages, files, and major historical entry points have identifiable records. Unknown materials have a pending review status. Production staff's memory does not determine the migration scope.
2. Check Purchasing and Support Tasks Before Removing Low-Traffic Content
Low-traffic technical information may be used for internal reviews, model checks, after-sales searches, or sales forwarding. Ask the responsible staff who uses it, at what stage, whether it is still accurate, whether a replacement exists, and who will maintain it. Privacy information and other necessary explanations should not be handled solely by visit counts either; the company confirms their specific applicability.
High traffic likewise does not mean content must be preserved unchanged. Visits unrelated to current business, outdated service descriptions, and incorrect specifications need reassessment. Visit data reflects entry-point performance; it does not replace factual review or automatically prove useful inquiries.
If search impressions are unavailable, distinguish missing data, an insufficient observation period, and a genuine absence of relevant impressions. Put materials still needed by the business but lacking a confirmed version into the review queue. Find an approver before deciding whether to keep them public. Do not translate “no one replied” into “no value.”
For further handling of low-traffic articles, consult methods for deciding when to revise, remove, or merge content. Reducing the total is not the acceptance criterion. Continuing useful tasks is.
3. Assign an Explainable Action to Each Content Item
Retain: If the content is accurate and its task remains relevant, migrate the body, media, metadata, and file relationships. Keep the original URL if there is no compelling reason to change it, avoiding unnecessary migration work.
Update or rewrite: If the topic and subject remain useful but information is outdated, evidence insufficient, or structure difficult to use, preserve necessary original content, correct changed facts, and add the conditions and next steps readers now need. Do more than replace the date.
Merge: If several pages serve the same task, choose a main page, combine their useful material, remove duplicate explanations, and check whether the new page supports the original keywords, references, and use cases. Pages with similar titles but different product versions should not be merged directly.
Replace: If an old service or product has a genuinely related new counterpart, confirm the differences and applicable conditions before arranging a corresponding entry point. Archive or delete: Content still needed for historical identification can retain an accurate status. If no task remains and there is no suitable replacement, assess removal. Leave unknown destinations pending rather than filling the mapping table with the homepage.
Completion check: Every decision has a reason, approver, and destination. A merged page explains the original subjects instead of mechanically combining them into a longer body.
4. Turn Content Decisions into URL and Field Migration Plans
Provide technical staff with page destinations together with content actions. Google's site migration documentation recommends URL mapping and server-side permanent redirects wherever possible. Sending many old URLs to an unrelated homepage may be treated as a soft 404. A shared destination is justified when several related old pages are genuinely combined into a complete new page.
For content selected for removal without a replacement, confirm an appropriate 404 or 410 response, clean up related internal links and sitemaps, and avoid error pages that still return 200. A custom error page can offer accurate search directions, but should not imply the original information still exists.
Migration also covers titles, descriptions, image alt text, authors and dates, internal links, downloads, canonical tags, and applicable hreflang. Structured data should reflect the new page's actual content, rather than automatically copying obsolete markup. Public access permissions, version applicability, and attachment integrity also need separate checks.
5. Review Materials and Editorial Responsibilities to Avoid Migrating Old Conflicts
During a redesign, versions of the same material often exist in the backend, cloud storage, and staff computers. Record their sources, applicable subjects, and confirmed versions first, and have the factual owner choose what to use. Completed page layout does not mean product specifications or service commitments have been approved.
Define factual confirmation, editing, and publishing responsibilities for important pages. For shared introductions or downloads, record where they are reused and track those locations together when updating. For ongoing maintenance, see corporate website content operations and responsibility planning.
When discussing a redesign with JVDS Design Studio, include the old-site inventory, preservation of important content, and URL migration as agreed work items. Confirm the specific review scope and implementation responsibilities individually. The company still supplies the basis for business facts.
6. Verify Historical Entry Points Individually After Launch
Open old URLs according to the inventory and check the response, final destination, product and language identity, file version, and contact path. Then check that the new pages' canonical tags, sitemaps, and internal links use confirmed URLs. Prioritize content with search visits, backlinks, sales references, and support tasks. Checking only the new menu is insufficient.
Retain important page snapshots from before and after launch and the scope of data observation. Continue checking error responses, crawling, indexing, and business receipt of requests. An anomaly may come from a missing mapping, changed content, or another configuration. Find evidence for these separately rather than attributing causes from total traffic changes alone.
Completion check: Historical entry points within the selected scope have reasonable outcomes, important materials and fields remain complete, pending reviews have owners, and later anomalies can be traced to specific decisions and pages.
Frequently Asked Questions
Can all pages with no traffic be deleted together?
First check external references, purchasing materials, support uses, and maintenance conditions. Missing traffic data also does not mean a page has no use.
Can old articles simply be dated today?
Only substantive updates should be accurately marked as updates, retaining the original publication date where necessary. Changing a date does not replace adding facts and correcting the body.
Does a working PDF download mean migration succeeded?
You must also confirm that the model, version, language, and permissions match the original task. An incorrect file can still open normally.
