A fresh look is not the same as a failing website
Website redesign warning signs are easier to judge when you separate a color preference from a problem you can test. A site can look dated and still help customers find hours, services and a working request path. Another site can look polished and still hide the phone number or block keyboard users.
That same polished site can also take so long to load that a visitor leaves. Rebuilds are large changes to structure, templates and often the publishing system. A repair can fix a menu, a form, a slow image or outdated copy without replacing the whole site.
The examples below are hypothetical, not client results or industry benchmarks.
Website redesign warning signs start with evidence
Write down the issue, the page where it appears and how you confirmed it. Note the device, browser and date of the test. A remark that the site “feels off” is not enough to choose a path.
Collect a short set of facts. Include whether the main menu works with a keyboard. Note whether a test inquiry arrived, and how long important pages take to become usable.
Keep screenshots and a note of what you expected to happen. That record helps you judge later whether a fix worked.
Separate taste from problems you can test
Taste includes a wish for new colors, a different hero photo or a typography change. Those preferences can be valid design work. They are not, by themselves, proof that the current site has stopped serving customers.
A testable problem blocks a task. One visitor cannot open the services menu on a phone. Another cannot submit a quote request or read required form fields.
Make two lists before you approve a large rebuild. Put visual preferences on one list and confirmed barriers on the other. If the second list is empty, start with a smaller visual update rather than a full replacement.
Website redesign warning signs belong on the second list only when you can show the failure.
Check whether menus work without a mouse
The Department of Justice published guidance on web accessibility and the ADA on March 18, 2022. It lists mouse-only navigation as a website accessibility barrier. It says people who cannot use a mouse or a trackpad will not be able to access the web content.
That is the case if they cannot use a website with a keyboard. The same guidance lists inaccessible online forms as another barrier. It also lists missing text alternatives and poor color contrast.
The page describes how businesses open to the public can make sure their websites are accessible to people with disabilities. The Department says it does not have a regulation that sets out detailed standards for those websites. It says existing technical standards such as the Web Content Accessibility Guidelines provide helpful guidance.
The page also states that the document is informal guidance and is not legally binding. It notes that the document does not reflect later Title II state and local government requirements published April 24, 2024.
WCAG 2.2 is a W3C Recommendation dated December 12, 2024. Success Criterion 2.1.1, Keyboard, is a Level A requirement. It says all functionality of the content is operable through a keyboard interface.
It also says this must not require specific timings for individual keystrokes. An exception applies where the underlying function requires path-dependent input. Success Criterion 2.4.7, Focus Visible, is Level AA.
It says any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Test your own menu against those statements. Open the site with the keyboard only, using Tab, Enter and the arrow keys where a menu requires them.
If a drop-down opens only on hover or traps the keyboard, record that as a confirmed barrier.
Watch for inquiry paths that lose requests
A weak inquiry path is another problem you can test. Send a sample request from a phone and a desktop computer. Confirm that the message arrived and that required fields are labeled in a way a visitor can follow.
A hypothetical heating company might display three different phone numbers. It might also use a contact form that fails on mobile. Replacing the entire site would not be the first step.
Fix the form, publish one number and then retest the request path. If the form works but asks for details customers do not yet have, field choice may be the issue. For help choosing those questions, see which questions belong on a small business contact form.
Measure slow pages against public thresholds
Google’s Core Web Vitals documentation identifies three metrics that apply to all web pages. Largest Contentful Paint measures loading performance. To provide a good user experience, it should occur within 2.5 seconds of when the page first starts loading.
Interaction to Next Paint measures interactivity and should be 200 milliseconds or less. Cumulative Layout Shift measures visual stability and should be 0.1 or less. Google says a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.
Tools should consider a page passing if it meets the recommended targets at the 75th percentile for all three metrics. Use field data to assess the percentile targets and lab tests to diagnose individual problems. Do not treat a single office-computer test as a complete picture.
A slow homepage can often be improved by compressing images, postponing unused scripts or fixing a heavy banner. Those are repairs. If the main failures appear on phones, test there first.
For a related mobile review list, see a mobile website checklist for small business sites.
Look for outdated or conflicting information
Conflicting hours, retired services and old addresses undermine trust even when the design still looks current. Check the homepage, contact page, footer and any location pages on the same day. If two published phone numbers or closing times disagree, fix the source record and update every page that repeats it.
A hypothetical salon might still advertise a weekday evening slot it no longer offers. That is a content repair. It becomes a rebuild issue only if staff cannot edit those details in a usable way.
Decide when a repair is enough
Choose a repair when the information structure still matches the business and the failures are limited. A broken mobile menu or a form that does not send can often be fixed in the current templates.
Start with the barrier that blocks the most complete tasks. Retest after each repair. If the keyboard menu now works and the test inquiry arrives, a full rebuild may not be needed.
Keep the evidence so a later review does not restart from memory. New colors or photos do not require a new information structure.
Decide when a rebuild is warranted
A rebuild is easier to justify when the current system cannot accept needed fixes. That may include templates that cannot expose a keyboard-operable menu. It may also include a form tool that cannot be tested or labeled correctly.
A mobile layout that loses content no matter how the existing theme is adjusted is another example. Also consider a rebuild when the site’s structure no longer matches the business. Services, locations or booking steps may have changed.
If every major page still describes an older model, a series of patches can leave visitors with conflicting paths. A planned rebuild can map the current work, contact routes and proof in one pass. Do not treat a rebuild as the only response to a new logo.
A new logo should not hide untested barriers or replace a site that already works. Website redesign warning signs should still be documented before the first layout is approved.
Website redesign warning signs that are only cosmetic
A site is not automatically due for replacement because a competitor launched a new look. An owner may also be tired of a header photo. Record those preferences, then return to the test list.
If customers can complete the main tasks, a smaller visual project may be enough. Watch for vague claims that a redesign will increase inquiries or search rankings. Those outcomes depend on many factors, and no percentage here is offered as a predicted result.
Judge the project by whether it removes confirmed barriers and makes accurate information easier to find. If a vendor proposes a rebuild after a short visual review and no testing, ask for the evidence. Request a keyboard test, a submitted inquiry and speed measurements for key pages.
Run a simple repair versus rebuild test
Give yourself a short, dated worksheet. List the top customer tasks, such as finding a service, checking hours, calling or sending a request. Try each task on a phone and a desktop computer, and mark pass, fail or unclear.
For every failure, ask whether the current site can be changed to remove it. If staff can fix the menu, form or image weight in the current system, classify it as a repair. If the system cannot support the change, classify it as a rebuild candidate.
Count the repair items and the rebuild candidates separately. A long repair list is not the same as a failed platform. Use the worksheet to keep website redesign warning signs tied to tasks you can repeat.
A hypothetical shop that needed a repair
Suppose a neighborhood bakery website looks several years old, and the owner wants new photos. Testing shows that the menu works with a keyboard. The order-inquiry form arrives, and the hours match the shop door.
One homepage image is large enough to delay loading on a phone. The first project is to compress or replace that image, confirm the contact path again and then update photos. A full rebuild would have replaced a working menu and form only to satisfy a visual preference.
A hypothetical clinic that needed a rebuild
Suppose a local clinic still uses a site built around a single scrolling page. Staff can no longer edit hours without help. The mobile menu cannot be opened with a keyboard.
The request form is a third-party box that never posts to the clinic inbox. Repeated patches have not made the menu or form usable. Here the failures sit in the structure and the tools, not only in one photo.
A rebuild can create editable pages, a keyboard-operable menu and a request path the staff can test. The rebuild is justified by barriers the current system cannot fix, not by a new color palette alone.
A repair and rebuild checklist
Before you approve a website replacement, review the record you already have.
- Separate visual preferences from failures you can test.
- Try the main menu with a keyboard and look for a visible focus indicator.
- Send a test inquiry from a phone and a desktop computer.
- Compare important pages with the published Core Web Vitals thresholds.
- Check hours, services and contact details for conflicts.
- Classify each issue as a repair or a rebuild candidate.
- Retest after any repair before expanding the project.
- Keep screenshots and dates with the final decision.
Start with the next failed task on your list, not with a blank design file. Sources were reviewed on November 11, 2026.
The information here is general and educational and is not marketing, financial, technical or legal advice for a specific business. Examples are hypothetical. Check your own site, measurements and advisors before you change a website or make public claims.
