10 Common Website Redesign Mistakes: Warning Signs, Causes, Prevention and How to Recover (2026)

A failed redesign rarely looks like a failure on launch day. The new site looks good and colleagues like it. The numbers start slipping a few weeks later.

Enquiries fall. Search traffic halves. The site feels heavy on a phone. The English version still shows old content. Most of these problems were built in months before launch, during planning and procurement.

This article sorts the most common redesign mistakes into ten patterns. For each one it covers warning signs, causes, prevention and recovery. We do not name real companies as failures; we only cite published research and official guidance.

Main sources for this article

• Google Search Central guidance on site moves, multilingual sites and indexing control
• web.dev Core Web Vitals thresholds and the Vodafone case study, HTTP Archive Web Almanac 2024, WebAIM Million 2026
• W3C WCAG 2.2, the European Accessibility Act (Directive 2019/882), the Dutch government's business portal business.gov.nl
• The McKinsey and University of Oxford study of IT projects (2012), plus guidance from Japan's Cabinet Office, Fair Trade Commission and IPA

What this article answers	Short answer
What counts as a failed redesign?	Results drop, budget and time overrun, no one runs it, or it breaks rules (section 1)
Which mistakes are most common?	Ten patterns, from no goal to weak contracts (section 2)
How do you prevent each one?	Signs, causes, prevention and recovery in each section (sections 3–12)
What if it already happened?	Stop the bleeding, isolate the cause, fix, prevent repeats (section 13)
How do Japan and Europe differ?	Legal deadlines, languages and contract types differ (section 14)

1. Defining a "failed" redesign

Failing to launch is not the only failure

Far more common than a collapsed project is a site that launched on time but did not achieve its purpose. This article treats failure as four types; if any applies, the redesign shows signs of failure.

Type of failure	What it looks like	When it shows
Results drop	Fewer enquiries, sales or search visits than before	2–12 weeks after launch
Budget and time overrun	Repeated change quotes, launch keeps slipping	Mid-project onwards
No one runs it	Updates stop, no owner	3–6 months after launch
Breaks the rules	Accessibility or cookie complaints	Any time

Failures usually surface long after their causes were introduced, which is what makes them hard to see.

Large IT projects show the same pattern

In 2012 McKinsey and the University of Oxford studied more than 5,400 IT projects. Large projects with initial budgets above USD 15 million ran on average 45% over budget and 7% over time, and delivered 56% less value than predicted. The causes it lists, from missing focus and shifting requirements to skills and execution, apply almost unchanged to much smaller website projects.

2. The ten failure patterns at a glance

Warning signs and where each one starts

Here are the ten patterns, with the early signs that reveal them and the stage at which they are introduced.

Failure pattern	Early warning sign	Introduced at
1. No clear goal	No one can say in one sentence what will improve	Planning
2. Design-only change	Meetings are mostly about colours and photos	Planning to design
3. Content left until last	No owner or deadline for copy	Design
4. Tracking gap	No list of key actions to measure	Build
5. Search traffic drop	No URL mapping	Design to launch
6. Slower pages	No speed target in the requirements	Design to build
7. Legal gaps	No one knows the accessibility standard	Planning to build
8. Broken languages	English is "translate later"	Design
9. No owner after launch	No one assigned for post-launch work	Planning
10. Weak procurement	Quote says only "complete website"	Procurement

The table shows that many of the ten are introduced during planning and design. The figure below maps where each is introduced and when it surfaces.

3. Mistake 1: Starting without a goal

Warning signs and causes

This is the most common mistake and the starting point for many others. The sign is simple: no one can say in one sentence what the redesign will improve.

"It looks dated" or "a competitor relaunched" are triggers, not goals. Without a goal, decisions rest on the taste of whoever is in the room.

Prevention: turn the goal into numbers

Before you start, turn the goal into numbers you can measure. The table pairs common goals with the numbers that measure them.

Common goal	Number to measure	Save before launch
More enquiries	Monthly enquiries, form completion rate	Last 12 months of counts
Stronger hiring	Applications, careers page views	Last 12 months of applications
More European customers	Traffic and enquiries by country	Figures by country
Update content in-house	Days needed per update	Current days and request flow
Faster pages	LCP, INP, CLS on mobile	PageSpeed Insights results

The right-hand column matters most. If you do not save the old site's numbers, you cannot tell whether the new site is better.

Recovery

If you realise after launch that the purpose was vague, it is not too late. Pick one or two target numbers now and pull what you can of the old site's figures from Search Console and GA4, then re-check the site with the measurements in ten signs your website needs a redesign.

4. Mistake 2: Changing only the design

Warning signs and causes

Most meetings end with discussions of colours, fonts and the homepage photo. That is the sign. Visuals are easy for everyone to comment on, so the conversation gravitates there.

What drives enquiries, however, is usually structure and paths, not looks. Where do visitors arrive, what do they read, and where do they get in touch? If that flow is the same as before, new visuals will not move the numbers much.

Prevention: separate looks from what drives results

Split the design discussion into parts that drive results and parts that do not. The table ranks common redesign elements by their effect on results.

Element	Effect on results	How to check
Page structure (information architecture)	Large	Tree testing: can people find things?
Enquiry path and forms	Large	Steps and drop-off to completion
Body content and case studies	Large	Search terms and reading time
Page speed	Medium to large	Core Web Vitals
Colours, fonts, photos	Small to medium	Readability and contrast

The elements that matter most are the least visible. If you change the look, review the structure and paths at the same time.

Recovery

If you already launched a looks-only redesign, review the paths on your top ten enquiry pages; a full redo is not needed. Shorter forms, a contact button within the body text, and links from case studies to the contact page often work better than another redesign.

5. Mistake 3: Leaving content migration until last

Warning signs and causes

Design and build are moving, yet no one owns the copy and there is no deadline. That is the sign.

Content migration means checking each page and deciding to keep, update, merge or remove it. It looks simple but scales with page count. Left until last, it creates a pile of manual work just before launch, which either delays launch or forces a poor migration.

Prevention: start with an inventory

Make a content inventory the first task. Nielsen Norman Group recommends first listing every page in an inventory and then auditing its quality.

The inventory lists title, URL, owner, topic, last update and metadata. Adding search traffic and enquiry figures makes decisions easier.

Decision	Typical condition	Old URL handling
Keep	Gets traffic or enquiries and is accurate	301 to the new URL
Update	Gets traffic but is outdated	Update, then 301
Merge	Several similar pages	301 to the merged page
Remove	No traffic and no remaining purpose	410 or 404; do not redirect to unrelated pages

Avoid redirecting every removed page to the homepage. Google says redirects to irrelevant pages may be treated as soft 404s, meaning pages that effectively do not exist.

Recovery

If you launched with many old pages missing, check the URLs returning 404 in the Search Console Pages report. In order of past traffic, add redirects to new pages or restore the content.

6. Mistake 4: A gap in tracking

Warning signs and causes

After the redesign someone says "enquiries seem lower", but no one can check it with data. That is a tracking gap.

The usual cause is that the tag was reinstalled on the new site, but key actions such as a completed enquiry are no longer recorded. When the form changes, the old tracking setup stops working.

Watch GA4 retention too: standard properties can keep user- and event-level data for 2 or 14 months, and explorations are affected by this setting. If no one checked it, older data may be gone when you want to compare.

Also, Universal Analytics stopped processing data for standard properties on 1 July 2023. If the old site only had the legacy tag, nothing after that date was recorded at all.

Prevention: list the actions to measure before launch

Before launch, list the actions to measure and confirm each one on staging.

Item to check	Before launch	Impact if missed
Key actions (e.g. completed enquiry)	Use the same event names old and new	No old-new comparison
GA4 retention period	Confirm it is set to 14 months	No year-on-year comparison
Search Console ownership	Verify new domains and URLs	Post-launch errors go unnoticed
Cookie consent setup	Confirm no tracking before consent	Legal breach, or no data at all
Old site's numbers	Export 12+ months and keep them	No baseline to compare

The fourth row matters most for European sites: tracking before consent is a legal problem, and a bad setup can stop measurement entirely.

Recovery

When you find a gap, fix the tag that day. Lost data will not come back, but you can often recount enquiries from email or CRM records.

Lining up the recounted enquiries by month before and after launch at least tells you whether they fell. To automate monitoring, see automating Search Console and GA4 monitoring.

7. Mistake 5: A sudden search traffic drop

Warning signs and causes

One or two weeks after launch, search traffic visibly drops.

Google's site move guide says visibility in Search may fluctuate temporarily during a move, and that it can take a few weeks or more for new URLs to show. Some movement is expected.

Large drops, however, are usually configuration gaps rather than fluctuation. The four common causes:

Cause	Where to check	Fix
Missing redirects	Crawl the list of old URLs	301 to the matching new URL
Leftover robots.txt or noindex	robots.txt and page meta tags	Remove staging blocks
Wrong canonical or sitemap	Page source and sitemap URLs	Point to live new URLs
Much less body content	Compare old and new top pages	Restore removed information

Google's guide explicitly reminds site owners not to forget to remove noindex or robots.txt blocks that were only needed for the migration. Staging settings reaching production is that common.

Prevention: build the URL map first

The core of prevention is a redirect map from old to new URLs. You can build it from the same inventory as section 5.

Google advises keeping redirects as long as possible, generally at least one year. Redirect types, configuration examples and the Search Console Change of Address tool are covered in our article on 301 redirects.

Recovery: respond according to the size of the drop

Respond differently depending on how far traffic has fallen. The figure shows the rule of thumb DevNJ uses. Because of seasonality, compare with the same period last year or the average of the four weeks before launch.

When the drop is large, work in this order:

1. In Search Console, list the 20 pages with the largest click losses
2. Open each old URL and confirm it 301-redirects to the right new URL
3. Check robots.txt and the noindex and canonical tags on those pages
4. Submit fixed URLs for recrawl with the URL Inspection tool
5. Record clicks for the same 20 pages weekly to track recovery

As a reported case, Search Engine Journal studied 892 domain migrations and reported an average of 523 days to regain previous traffic. This is an average of reported cases, not a rule, but moves that also change the domain can take long to recover.

8. Mistake 6: Slower pages

Warning signs and causes

The new site is slower than the old one. This is surprisingly common. Large photos and video, animation, and third-party chat or ad tags pile up without a check.

Teams test on fast connections and laptops, so they miss it. Real users visit on phones on the move.

Prevention: put pass marks in the requirements

web.dev defines "good" Core Web Vitals at the 75th percentile of real users as follows. Write these straight into the redesign requirements and acceptance criteria.

Metric	What it measures	Good threshold
LCP	Time until the main content shows	2.5 seconds or less
INP	How fast the page responds to input	200 milliseconds or less
CLS	Layout shift while loading	0.1 or less

Slowness is not rare. According to HTTP Archive's Web Almanac 2024, only 43% of sites on mobile and 54% on desktop passed all three metrics. Around half of sites do not pass.

A published case where speed moved results

web.dev describes a Vodafone case published in 2021. A version with a 31% better LCP saw 8% more sales, a 15% higher lead-to-visit rate and an 11% higher cart-to-visit rate.

This is a large e-commerce case, and a small business site will not necessarily see the same percentages. It does show that speed affects business numbers, not just perceived quality.

Recovery

If the site got slower, measure your top pages with PageSpeed Insights and tackle the biggest causes first. Three fixes usually help most:

• Replace large hero images with correctly sized, modern formats
• Remove unused third-party tags, such as those from old campaigns
• Replace above-the-fold video or sliders with a still image

9. Mistake 7: Accessibility and legal gaps

Warning signs and causes

"Accessibility next time." "We'll sort the cookie banner after launch." Postponements like these are the sign. Both cause rework in design and build if added later.

WebAIM's February 2026 check of the home pages of the top one million sites detected WCAG failures on 95.9%. The most common was low contrast (83.9%), followed by missing alternative text and missing form labels. A redesign is exactly the moment to fix these in one go.

Deadlines are piling up in Japan and Europe

In recent years, deadlines affecting websites have followed one another in both Japan and Europe. The figure lists the main dates relevant to redesign requirements.

The table sorts them by Japan, the EU and the Netherlands.

Region	Law or guidance	Effect on the website
Japan	Amended Act on the Elimination of Disability Discrimination (from 1 April 2024)	Reasonable accommodation mandatory for businesses; web is part of the environment
Japan	External transmission rules, Telecommunications Business Act	In-scope businesses must disclose data sent to third parties
EU	European Accessibility Act (applies from 28 June 2025)	Consumer e-commerce, booking, banking and more
Netherlands	National supervision of the Act	ACM supervises e-commerce; an accessibility statement is required
Netherlands	Cookies and GDPR	AP checks banners; tracking before consent may be unlawful

Under the European Accessibility Act, services provided by microenterprises with fewer than 10 staff and annual turnover or balance sheet total of no more than EUR 2 million are exempt (Directive 2019/882, Article 4). A Japanese company can still be in scope if it offers services such as e-commerce to EU consumers.

Prevention: write the standard into the requirements

For accessibility, the usual approach is to write WCAG 2.2 level AA from W3C into the requirements. Without a stated standard, an agency cannot quote for it.

For cookies, add two pre-launch checks: is rejecting as easy as accepting, and do analytics or ad tags stay off until consent? The Dutch AP says it scanned the cookie banners of 10,000 sites and sent warnings to more than 200.

Recovery

If gaps are found after launch, fix form labels, keyboard operation and contrast first. W3C's WAI publishes evaluation approaches from quick checks to expert reviews.

10. Mistake 8: Broken languages

Warning signs and causes

Only the Japanese version is new while English still runs on the old site. English URLs do not match Japanese ones. The language switch sends you to the homepage. These are broken languages.

The cause is treating multilingual work as "translate after Japanese is done". URL structure per language, the switching mechanism, translation ownership and update flow must be settled in design, or aligning them later becomes hard.

Google's guidance and common breakages

Google gives clear guidance on multilingual sites. The table pairs common breakages with that guidance.

Common breakage	Google's guidance	Prevention
Auto-redirect by browser language	Do not redirect based on a guessed language	Let users choose
One URL switches language	Use different URLs per language	Separate /ja/ and /en/
Only boilerplate translated	Body in one language makes a poor experience	Translate the body too
Translation pairs out of sync	Use hreflang to link language versions	Link versions to each other
Switch jumps to homepage	—	Link to the same page in the other language

The first row is especially common on European sites.

Prevention: make language a unit of design

In a multilingual redesign, list pages per language and decide which page translates which at the start. That mapping feeds both hreflang and the redirect map.

Design and pitfalls of automating translation are covered in automating translation for a bilingual site.

Recovery

If languages are broken, stop auto-redirects first. Then rebuild the mapping between language versions and align hreflang and the switch links.

11. Mistake 9: No one runs the site after launch

Warning signs and causes

Launch is treated as the finish line, and no one has decided who does what afterwards. It shows as news that stops for six months, no new case studies, or form errors no one notices.

The cause is that the redesign gets a project budget while ongoing work is left as someone's side job.

Prevention: put roles and frequency in a table

Before launch, put post-launch roles and frequency in a table. Any row without a person's name will stall.

Role	Frequency	Main tasks
Content updates	Weekly	News, case studies, vacancies
Numbers	Monthly	Enquiries, traffic and speed, shared with the team
Technical maintenance	Monthly	CMS and plugin updates, backups
Legal review	Once or twice a year	Cookies, privacy, accessibility statement
Translation	Each update	Reflect changes in other languages

Recovery

If upkeep has stalled, do not try to restart everything at once. Restart the monthly numbers check first and use it to choose one or two pages to improve next.

12. Mistake 10: Weak procurement and contracts

Warning signs and causes

The quote says only "complete website" and you cannot tell what is included. The number of revision rounds and how changes are handled are not written down. Such vagueness surfaces mid-project as extra costs and delays.

The cause is comparing prices before the scope is fixed. How to read a quote is covered item by item in redesign costs and how to read a quote.

Prevention: five things to settle in the contract

Before signing, settle at least these five in writing.

What to settle	What happens if you don't	Example wording
Scope	Migration and redirects fall outside scope	Number of pages migrated, number of redirects
Deliverables and acceptance	Disputes over what "done" means	Speed and accessibility pass marks
Change handling	Extra costs pile up	Hourly rate and approval steps
Post-launch maintenance	Unclear whether fixes are paid	Scope, period and response times
Ownership and rights	You cannot take over domain or code	Domain, hosting and CMS in the client's name

In Japan, liability differs depending on whether the contract is a fixed-result contract (ukeoi), where the supplier answers for completion, or a service contract (jun-inin), where it answers for performing the work. IPA publishes model contracts that explain responsibilities by phase for system development.

When hiring an individual freelancer in Japan, the Freelance Act in force since 1 November 2024 requires the client to state the work, fee and payment date. Dutch agencies usually quote by the hour rather than a total; surveys put the agency average at €106 per hour and freelance web developers at €73 (both excluding VAT).

Recovery

If you are already disputing scope, list the remaining work and sort it into in scope, out of scope and undecided.

If the relationship cannot continue, secure ownership and admin access for the domain, hosting, CMS and source code first. Without them, another agency cannot take over.

13. Recovering after the fact: four common stages

Don't roll back in a panic

When numbers fall after launch, someone will suggest going back to the old site. But rolling back changes the URLs again and makes search signals even less stable. Investigating the cause first is rarely too late.

The table summarises the recovery flow common to all ten patterns in four stages.

Stage	Typical duration	What to do
1. Stop the bleeding	Same day to 3 days	Check robots.txt, noindex, tracking tags and forms
2. Isolate the cause	1–2 weeks	Identify affected pages and timing; match to the ten patterns
3. Fix	2–6 weeks	Fix redirects, content, speed and paths, biggest impact first
4. Prevent repeats	1–3 months	Update the checklist and post-launch roles

Durations are DevNJ's rule of thumb and vary with site size and cause.

Effort and cost ranges for recovery

Recovery costs vary widely by cause. The table converts typical effort into money using Dutch hourly rate surveys (€73–€106).

Fix	Typical effort	Cost range (excl. VAT)
Fix robots.txt and noindex	1–2 hours	€73–€212
Reinstall tracking tags and events	4–8 hours	€292–€848
Add redirects for top pages (up to 100)	4–12 hours	€292–€1,272
Speed up top pages	8–24 hours	€584–€2,544
Main accessibility fixes	16–40 hours	€1,168–€4,240

Effort figures are DevNJ's estimates; real quotes depend on the platform and volume. Convert to yen at the current rate. The point is that configuration gaps are cheap to fix, while design-level rework is expensive.

14. How failures differ between Japan and Europe

Same mistake, different weight

For sites aimed at both Japan and Europe, the same mistake can have different effects, especially in law, languages and tracking.

Area	Sites for Japan	Sites for Europe
Accessibility	Reasonable accommodation duty; JIS X 8341-3 is the usual web reference	European Accessibility Act; WCAG 2.2 is the practical benchmark
Cookies and tracking	External transmission rules (in-scope businesses)	Tracking before consent may be unlawful; regulators check
Languages	Often Japanese only	Two or three languages are normal
Search engines	Google and Yahoo! JAPAN (Google technology)	Mostly Google; Bing has a share
Contract type	Ukeoi or jun-inin; Freelance Act	Usually hourly, built up from estimates

On European sites tracking before consent is a legal issue, so mistakes 4 and 7 often occur together; one person should own both consent and measurement.

15. Case studies (fictional examples)

The following uses fictional companies to show how failures cascade and how to recover. They are not real companies or cases.

Case A: A manufacturer that changed the design and halved its enquiries

Company A, a Japanese parts maker, prompted by a competitor's new site, completely changed its homepage photos and design. Two months after launch, enquiries fell from 20 to 10 a month.

The "technical documents" pages that had generated many enquiries had been removed during migration, so engineers arriving from search hit dead ends. Company A restored the pages, added 301s from the old URLs, and added a path from the documents to the contact form.

Case B: A service company whose auto-redirect confused Dutch users

Company B, a Japanese service firm based in the Netherlands, added auto-redirects by browser language during its redesign. Japanese users on Dutch-language computers could no longer reach the Japanese version.

Company B removed the auto-redirect and showed a language choice on the first visit instead. It also reset hreflang between the versions.

Case C: A retailer whose launch slipped three months over scope

Company C, which sells online to EU consumers, hired an agency on a "complete website" quote. Mid-project it emerged that migrating 800 old product pages was out of scope, causing extra cost and delay.

Case	Main mistakes	Core of the recovery
A (manufacturer)	2 Design-only, 3 Late content	Restore removed pages with 301s, add paths
B (services)	8 Broken languages	Stop auto-redirect, reset hreflang
C (retail)	10 Contract, 7 Legal	Redefine scope, add accessibility requirements

16. Pre- and post-launch checklist

Finally, here are checks that prevent the ten patterns. Use them one month before launch, on launch day and for 90 days after. The project flow itself is covered in redesign process and schedule.

Planning and procurement

• The goal fits in one sentence and the numbers to measure are set
• At least 12 months of the old site's numbers are exported and saved
• The quote includes migration, redirects, languages, accessibility and maintenance
• Post-launch roles have named owners

Design and build

• Every page is in an inventory with a keep, update, merge or remove decision
• There is a map from old URLs to new URLs
• Speed (LCP, INP, CLS) and accessibility (WCAG 2.2 AA) pass marks are in the requirements
• No analytics or ad tags run before cookie consent

Launch day and the first 90 days

• No staging blocks remain in robots.txt or noindex tags
• Top old URLs 301-redirect to the correct new URLs
• Key actions such as completed enquiries are recorded
• Goal numbers are compared with the old site at weeks 4, 8 and 12

Summary

• Think of redesign failure as four types: results drop, budget and time overrun, no one runs it, or it breaks the rules
• Most of the ten patterns are introduced in planning and design and surface within 90 days of launch
• The usual starting point is no goal. Before starting, decide which number should move and by how much, and save the old site's numbers
• A content inventory and URL map prevent three failures at once: migration, redirects and languages
• When procuring, settle scope, acceptance, changes, maintenance and ownership in writing

Sources

Search and analytics (Google and others)

• Site moves with URL changes — Google Search Central: fluctuation, timing, redirects for at least one year, leftover blocks
• Managing multi-regional and multilingual sites — Google Search Central: no auto-redirects, separate URLs, full translation
• Tell Google about localized versions of your page — Google Search Central: hreflang setup
• Block search indexing with noindex — Google Search Central: how noindex works
• Introduction to robots.txt — Google Search Central: the role of robots.txt
• HTTP status codes and network errors — Google Search Central: how soft 404s are handled
• Change of Address tool — Search Console Help: domain moves
• Universal Analytics has been replaced — Google Analytics Help: processing ended 1 July 2023
• Data retention — Google Analytics Help: GA4 retention of 2 or 14 months
• Study of 892 domain migrations — Search Engine Journal: average 523 days (reported cases)

Speed and accessibility

• Web Vitals — web.dev: LCP, INP and CLS thresholds at the 75th percentile
• Vodafone case study — web.dev: 31% better LCP, 8% more sales
• PageSpeed Insights: measuring speed
• Web Almanac 2024 Performance — HTTP Archive: pass rates 43% / 54%
• WebAIM Million — WebAIM: failures on 95.9% of home pages
• WCAG 2.2 — W3C: the accessibility standard
• Evaluating Web Accessibility — W3C WAI: evaluation approaches

Law and regulation

• Directive (EU) 2019/882 — EUR-Lex: the Act, microenterprise exemption, application date
• European Accessibility Act — European Commission: products and services covered
• European Accessibility Act — business.gov.nl: Dutch supervisors and accessibility statement
• AP pakt misleidende cookiebanners aan — Autoriteit Persoonsgegevens: cookie banner checks
• Cookie banner follow-up — Autoriteit Persoonsgegevens: fixes after warnings
• Amended disability discrimination act — Cabinet Office of Japan: reasonable accommodation mandatory from 1 April 2024
• External transmission rules — Ministry of Internal Affairs and Communications: Telecommunications Business Act disclosure rules
• Freelance Act — Japan Fair Trade Commission: duty to state terms in writing

Projects and procurement

• Delivering large-scale IT projects on time, on budget, and on value — McKinsey: 5,400+ projects, overruns
• Model IT transaction contracts — IPA: model contracts
• Content Audits — Nielsen Norman Group: inventory versus audit
• Benchmark report Agencies Q4 2025 — Simplicate: average Dutch agency hourly rate (€106)
• Web developer zzp hourly rates — Knab: freelance web developer hourly rate (€73)

All sources were checked on 26 October 2026. Rules and figures change, so check the official sites for the latest information before making decisions.