Most website redesign problems are visible before launch. They just aren’t written down.
The new homepage gets approved before anyone checks the old top landing pages. The developer changes URL structure without a redirect map. The owner wants the site to feel modern, but nobody defines what should happen to the quote form, checkout flow, local pages, analytics, accessibility, or post-launch support.
That is how a redesign turns into a revenue leak.
A risk register is not corporate paperwork. It’s a shared list of what could go wrong, how much it matters, who owns it, and what the team will do before the risk becomes expensive. Project teams need this because PMI’s 2025 Pulse of the Profession report focuses heavily on whether projects create business value, not just whether tasks get finished, and PMI says project professionals need stronger business acumen to keep projects connected to strategy. A website redesign is no different. A pretty site that loses leads, search traffic, or customer trust is not a win.
Use this as a working risk register before kickoff, during weekly status calls, and again before launch. If you’re hiring a web team, send them this page and ask how they handle each section. If you’re the agency, use it to show clients you are managing the business risk, not just the build.
What Is a Website Redesign Risk Register?
A website redesign risk register is a table that tracks the problems most likely to hurt the project. It usually includes the risk, impact, warning signs, owner, mitigation plan, and launch check.
For a website project, the risk categories are predictable: strategy, scope, content, SEO, design, development, performance, accessibility, security, analytics, launch, and ownership. Google’s site move guidance tells teams to prepare the new site, test thoroughly, map old URLs to new URLs, and configure redirects when URLs change. That single example shows why a redesign is not just a design task. It affects search, dev, content, QA, hosting, and business operations.
The goal is not to eliminate every risk. That never happens. The goal is to stop preventable mistakes from getting discovered by customers, Google, or the owner on launch day.
How to Score Redesign Risk
Keep the scoring simple enough that people will actually use it.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare | Annoying, but easy to fix |
| 2 | Possible | Causes rework or delay |
| 3 | Likely | Affects launch, revenue, rankings, or trust |
Multiply likelihood by impact. Anything scoring 6 or 9 needs an owner before the next project meeting.
This matters because website projects have a lot of hidden dependencies. GoodFirms says small business website costs can range from $1,500 to $10,000 or more, and larger web development projects can run far higher depending on requirements, features, complexity, technology stack, timeline, and team location. When requirements are fuzzy, the budget becomes fuzzy too.
Strategy and Business Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 1 | No agreed business goal | A redesign can become a taste contest instead of a revenue project. | Define the primary goal: more calls, better leads, ecommerce sales, recruiting, bookings, or support reduction. |
| 2 | Wrong audience priority | The homepage tries to serve everyone and persuades nobody. | Rank audiences before wireframes: buyers, repeat customers, job seekers, referral partners, investors, or support users. |
| 3 | No baseline metrics | Nobody can tell whether the new site improved anything. | Capture current traffic, leads, conversion rate, rankings, page speed, calls, form fills, and sales-qualified inquiries. |
| 4 | Decision makers enter late | Late executive feedback can undo weeks of design and content work. | Name final approvers before kickoff and schedule approval points. |
| 5 | Brand refresh becomes brand confusion | New language, colors, and offers make the business harder to understand. | Keep a message map with positioning, proof points, offers, and disallowed claims. |
A redesign should start with the commercial job of the site. Google describes Core Web Vitals as real-world user experience metrics for loading performance, interactivity, and visual stability, and recommends that site owners achieve good Core Web Vitals for Search and for users. That is a good reminder: design choices are not just aesthetic. They affect performance, search visibility, and conversions.
Scope, Budget, and Timeline Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 6 | Page count is not locked | Every new page adds strategy, writing, design, build, SEO, QA, and approval time. | Approve a launch page inventory and list phase-two pages separately. |
| 7 | Custom features are underestimated | Calculators, directories, portals, quoting tools, and booking flows are mini software projects. | Write acceptance criteria before pricing the feature. |
| 8 | Content ownership is vague | The project waits while everyone assumes someone else is writing pages. | Assign one owner for each page, asset, and review. |
| 9 | Integration work is undefined | CRMs, email tools, payment systems, calendars, maps, chat, and analytics can break quietly. | List every integration, account owner, login source, webhook, and test case. |
| 10 | Change requests are informal | A few small requests can quietly become a different project. | Use written change orders with cost, timeline, and approval impact. |
| 11 | Launch date is chosen before scope | The team backs into a deadline that was never realistic. | Set the launch date after page inventory, content status, feature scope, and approval paths are known. |
Good timelines are built from dependencies, not hope. GoodFirms reported that a small business website in the $1,000 to $7,000 range can take 1 to 12 weeks, while product MVP sites can require 3 to 12 weeks depending on scope. A five-page brochure site and a lead-generation site with 40 service pages, migration work, forms, tracking, copywriting, and CRM routing are not the same job.
SEO and Traffic Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 12 | No URL inventory | Old pages with rankings, backlinks, and referral traffic get deleted. | Crawl the old site and export URLs from analytics, Search Console, sitemap files, and backlink tools. |
| 13 | No redirect map | Users and search engines hit 404s after launch. | Map every old URL to the closest relevant new URL before development freeze. |
| 14 | High-value pages are rewritten blindly | Pages that rank or convert lose the language that made them work. | Mark keep, improve, merge, and remove decisions using traffic and lead data. |
| 15 | Title tags and meta descriptions are reset | Search snippets and relevance signals change across the site. | Export current metadata and approve new metadata before launch. |
| 16 | Internal links are broken or weakened | Important pages lose crawl paths and contextual relevance. | QA navigation, footer links, body links, breadcrumbs, related posts, and XML sitemap. |
| 17 | Robots or noindex settings are wrong | The new site can block search engines. | Check robots.txt, meta robots, canonical tags, sitemap, and staging protections before and after launch. |
| 18 | Local SEO pages are merged too aggressively | Service area visibility can drop when location intent disappears. | Keep high-intent service and location combinations that already bring qualified traffic. |
| 19 | Structured data is removed | Rich results and entity clarity can weaken. | Validate organization, local business, article, product, FAQ, review, and breadcrumb schema where appropriate. |
Google is clear about migration basics. Its site move documentation recommends preparing a URL mapping from current URLs to the new format and redirecting old URLs to new URLs. Google also recommends permanent server-side redirects when a page’s URL needs to change in search results. Skipping this work is one of the fastest ways to make a redesign look successful on launch day and painful 30 days later.
Content and Conversion Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 20 | The new copy is prettier but less specific | Visitors can’t tell what you do, who you serve, or why they should trust you. | Keep copy tied to services, proof, locations, industries, outcomes, and objections. |
| 21 | CTAs are inconsistent | Users see too many competing next steps. | Pick one primary CTA and one secondary CTA per page type. |
| 22 | Forms ask for too much too early | More friction can reduce inquiries. | Ask only for fields needed to route, qualify, or respond. |
| 23 | Proof gets buried | Case studies, reviews, certifications, partners, and numbers are hidden below generic copy. | Add proof near claims and conversion points. |
| 24 | Offers do not match buying stage | Cold visitors get pushed straight to sales when they need a guide, checklist, or quote prep tool. | Match CTAs to intent: contact, quote, audit, estimate, guide, demo, booking, or call. |
| 25 | Thank-you pages are ignored | The site misses tracking, next steps, and sales handoff opportunities. | Create thank-you pages with tracking, expectations, related resources, and CRM confirmation. |
Conversion risk is real even when the site looks better. Baymard’s 2026 checkout research calculates the average documented online shopping cart abandonment rate at 70.22% and reports that 18% of US online shoppers have abandoned an order because checkout was too long or complicated. Not every small business runs ecommerce, but the lesson carries over to lead generation. Every extra field, unclear next step, or trust gap gives the visitor another reason to leave.
Design, UX, and Accessibility Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 26 | Design prioritizes novelty over clarity | Users have to learn the site instead of using it. | Test navigation labels, homepage hierarchy, service paths, and mobile interactions. |
| 27 | Mobile layouts are treated as leftovers | Many visitors judge the business from a small screen. | Review every key page and form on real mobile devices. |
| 28 | Contrast is too low | Text becomes hard to read and can create accessibility failures. | Check color contrast before development, not after launch. |
| 29 | Buttons and links are unclear | Users miss the next step or click the wrong thing. | Use descriptive labels, visible focus states, and clear tap targets. |
| 30 | Accessibility is tested too late | Fixes become expensive when they require design and code changes. | Include accessibility checks in design review, component build, content entry, and QA. |
| 31 | Motion and animation distract from tasks | Effects can slow users down or create discomfort. | Use motion sparingly and respect reduced-motion preferences. |
Accessibility risk is not theoretical. WebAIM’s 2026 analysis of the top 1,000,000 home pages found 56,114,377 distinct accessibility errors, an average of 56.1 errors per page. The same report found that 95.9% of home pages had detected WCAG failures, with low contrast text appearing on 83.9% of home pages and missing form input labels on 51%. Those are common redesign mistakes because they often come from design systems, content entry, and components, not one-off bugs.
Development, Performance, and Security Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 32 | The site gets heavier | Larger pages can load slower, especially on mobile devices and weaker connections. | Set budgets for page weight, images, JavaScript, fonts, and third-party scripts. |
| 33 | Third-party scripts pile up | Chat widgets, pixels, heatmaps, schedulers, ads, and reviews can slow pages and create privacy risk. | Audit each script for owner, purpose, load impact, and removal criteria. |
| 34 | CMS permissions are too loose | Too many admin accounts increase mistake and security risk. | Use role-based access, MFA where possible, and remove unused users. |
| 35 | Plugin or package choices are not maintained | Old dependencies become security and maintenance problems. | Check update history, ownership, issue history, and replacement paths. |
| 36 | Forms fail silently | Leads disappear without anyone noticing. | Test every form, notification, spam filter, CRM handoff, and autoresponder. |
| 37 | Backups and rollback are not ready | A launch problem becomes an outage. | Confirm backup, rollback, DNS, hosting access, and responsible contacts before launch. |
| 38 | Cookie and privacy requirements are missed | Tracking and data collection can create compliance exposure. | Review analytics, consent, privacy policy, form disclosures, and data retention. |
Performance issues are easier to prevent than fix after a redesign. HTTP Archive’s 2025 Web Almanac reported that median inner page weight grew from 1,366 KB on mobile in May 2022 to 1,769 KB on mobile in July 2025. Its performance chapter also reported that only 56% of origins had good Core Web Vitals in 2025. Heavy pages are often the result of normal redesign decisions: bigger images, more animation, more tracking, more fonts, and more third-party tools.
Security deserves the same early attention. IBM’s 2025 Cost of a Data Breach research reported that the global average breach cost dropped to $4.44 million, still a serious business cost. Verizon’s 2025 DBIR credential stuffing research found that credential stuffing accounted for a median 19% of all authentication attempts in SSO provider logs, with small businesses experiencing 12%. A small business website may not feel like a security target, but admin accounts, forms, plugins, and customer data still need adult supervision.
Launch and Post-Launch Risks
| # | Risk | Why it hurts | Mitigation |
|---|---|---|---|
| 39 | Launch checklist is incomplete | DNS, SSL, redirects, forms, analytics, and caching issues show up in public. | Use a launch checklist with named owners and timestamps. |
| 40 | Analytics are not validated | The business loses visibility right when it needs it most. | Test GA4, Search Console, ad pixels, call tracking, CRM events, and form conversions. |
| 41 | No 404 monitoring | Broken URLs stay broken while traffic leaks. | Review crawl errors, server logs, Search Console, and analytics after launch. |
| 42 | No post-launch content plan | The new site goes stale after the announcement. | Schedule priority updates, landing pages, case studies, and blog topics. |
| 43 | Nobody owns maintenance | Updates, backups, security patches, and broken forms get ignored. | Define monthly ownership, support response times, and escalation paths. |
| 44 | Team training is skipped | Staff break layouts or avoid using the CMS. | Record short training videos and document common editing tasks. |
| 45 | Sales handoff is not tested | Leads arrive without the right context or follow-up process. | Test lead routing, notifications, CRM fields, source attribution, and response expectations. |
| 46 | The old site is shut off too quickly | Missing assets, redirects, and historical references are harder to recover. | Keep an archive, export media, and save database backups. |
| 47 | No 30-day review | The project ends before real-world issues surface. | Schedule a 7-day, 30-day, and 90-day review for traffic, leads, rankings, speed, errors, and user feedback. |
The first month after launch is not a victory lap. It is a monitoring window. Google’s Search Console change of address documentation explains that redirects and canonical tags can help reduce old URLs shown in Search when equivalent pages exist on a new site. That kind of post-launch verification is where teams catch problems before a redesign turns into a slow traffic decline.
Copy-and-Paste Website Redesign Risk Register Template
Use this table in your kickoff doc or project management tool.
| Risk | Category | Likelihood 1-3 | Impact 1-3 | Score | Owner | Mitigation | Due date | Status |
|---|---|---|---|---|---|---|---|---|
| Example: Missing redirect map | SEO | 3 | 3 | 9 | SEO lead | Export old URLs, map redirects, test after launch | Before dev freeze | Open |
| Example: Forms not tested | Conversion | 2 | 3 | 6 | Developer | Submit test leads through every form and verify CRM routing | Launch week | Open |
| Example: Low contrast buttons | Accessibility | 2 | 2 | 4 | Designer | Check contrast ratios before build handoff | Design approval | Open |
If you want a cleaner handoff, require every risk with a score of 6 or higher to have a named owner and a mitigation plan before design approval. Require every risk with a score of 9 to be reviewed in each status meeting until it is closed or accepted in writing.
The Practical Way to Use This
Do not send this to a team and ask, “Any concerns?” That question gets vague answers.
Ask sharper questions:
- Which risks here are most likely on our project?
- Which risks would cost us the most money if they happened?
- Which risks do we need to accept because the budget or timeline does not support more work?
That last question is honest. Not every project needs enterprise-level testing, security, content strategy, or custom analytics. But every business should know what is being skipped and why.
A good redesign feels calm because the scary stuff was discussed early. The team knows which pages matter, which URLs must survive, which forms drive revenue, which scripts are allowed, which people approve the work, and what happens if launch day gets messy.
If you want help planning a redesign without losing traffic, leads, or weeks of momentum, start with Your Web Team’s get started page. We’ll help you turn the unknowns into a build plan before they become expensive.
Richard Kastl
Founder & Lead EngineerRichard Kastl has spent 14 years engineering websites that generate revenue. He combines expertise in web development, SEO, digital marketing, and conversion optimization to build sites that make the phone ring. His work has helped generate over $30M in pipeline for clients ranging from industrial manufacturers to SaaS companies.
