# Signs that an old website needs an update Prioritize observable problems: inaccurate information, broken enquiries, unreadable mobile pages and unsupported dependencies. A new visual trend alone is a weak reason to rebuild. Correct an outdated service area and a failed form before replacing every page illustration. Do not promise an unmeasured percentage increase in sales or speed after a redesign. Before changing addresses, make a simple map from important existing pages to their intended replacements. Include pages reached through old emails, printed material or customer bookmarks, not only the current navigation. A redesign that improves the homepage but breaks those routes can create avoidable confusion. Preserve a sensible destination when the content still has a genuine counterpart. Define the rollback decision in advance. If the newly deployed form fails or important pages are unavailable, know which version can be restored and who has access to do it. This does not require treating a small site like a large enterprise system; it requires a recoverable release and clear responsibility. Keep the issue inventory after launch so the team can verify that the specific problems motivating the redesign were actually solved. A new appearance is an output; corrected information, usable navigation and reliable enquiries are observable outcomes. ## Build an issue inventory before choosing a redesign A website needs attention when observable problems stop it from representing or serving the business properly. Begin with factual accuracy: services offered, coverage, opening hours, package information and contact details. An attractive page that publishes outdated facts can create more confusion than an older visual style with correct information. Next, test the important journeys. Can visitors find the appropriate service, understand the scope and make contact? Does a valid submission create a real retrievable enquiry? Do failures explain what happened? A form can look unchanged for years while its underlying delivery path has stopped working, so inspect outcomes rather than the appearance of the button. Record each issue with the affected page, the observed behavior and its practical consequence. Avoid a list composed only of preferences such as the site feels dated. Preferences can matter, but they should be distinguished from broken functionality and inaccurate content. This makes it easier to decide which changes are urgent and which belong in a broader design project. ## Separate repairs from structural problems Some issues are small repairs: a broken link, an incorrect opening time or an image without useful text. Others suggest a larger content or technical problem. If every service page repeats the same vague message, the information architecture may need revision. If the site cannot be updated without an abandoned system or inaccessible account, continuity may require a more substantial rebuild. Review mobile behavior with actual tasks. Check menu operation, long headings, price wrapping and form input while the on-screen keyboard is open. Determine whether problems arise from a few layout rules or from a design that fundamentally assumes a wide screen. A desktop screenshot alone cannot answer that question. Inspect ownership and maintenance information. Identify the source code, current host, domain account and any paid dependencies. If none can be located, resolve access and documentation before starting changes that could disrupt the live site. A redesign should improve maintainability rather than reproduce the same account uncertainty in a new visual shell. ## Prioritize by impact and preserve what is useful Create a simple priority order. Correct misleading business facts and broken enquiry paths first. Address barriers that make key content unreadable or unreachable. Then plan deeper improvements to navigation, content quality and visual consistency. Optional animation or decorative changes should not consume the effort needed to make essential tasks work. Keep useful existing content when it remains accurate and relevant. A rebuild is not a reason to discard every service explanation or established URL. Map important old pages to their new counterparts and plan appropriate redirects where addresses change. Deleted material should receive a deliberate response rather than making every missing URL open the homepage with a success status. Use an illustrative repair business as a planning exercise. Its service region is outdated, the mobile menu covers the enquiry button and the form no longer saves requests. Those three issues deserve attention before a new set of photographs. If the existing architecture can support clean repairs, a full rebuild may not be necessary. If the content structure and implementation are both unsuitable, a broader project can be justified with evidence. Define what improvement will be checked. You can verify that the menu works, information is correct, the form stores a request and images are appropriately prepared. Do not promise an unmeasured percentage increase in revenue, conversion or speed. If performance is measured, record the tool, page and conditions and distinguish laboratory findings from real-user experience. Finally, plan a controlled release and a way to recover if something fails. Review the new pages with real content, preserve account access and retain deployment notes. The purpose of renewal is a more accurate, usable and maintainable website, not simply a newer appearance that leaves the same operational problems underneath. ## Practical checklist - Audit important journeys - Record broken links - Rank issues by business impact **A concrete example:** Correct an outdated service area and a failed form before replacing every page illustration. **A boundary to keep clear:** Do not promise an unmeasured percentage increase in sales or speed after a redesign. ## Your next step [Tell Orvunweb about your project](/en/start-a-project/) ## Related reading - [How to check whether a website is mobile friendly](/en/blog/how-to-check-whether-a-website-is-mobile-friendly/) - [Common choices that slow down websites](/en/blog/common-choices-that-slow-down-websites/) - [Keeping a website current after launch](/en/blog/keeping-a-website-current-after-launch/) - [Business website service](/en/services/business-website/) - [Compare packages](/en/pricing/) ## Related services - [Website redesign](/en/services/website-redesign/) - [Business website](/en/services/business-website/) --- Locale: en Canonical: https://orvunweb.com/en/blog/signs-that-an-old-website-needs-an-update/ Updated: 2026-09-16