Plan the website redesign before you plan the pages

1. Write a business case a finance leader can understand

“The website looks old” may be true, but it is not a sufficient investment case. Describe where the current platform creates cost, risk, or missed opportunity. Connect each issue to evidence and to a decision the new platform must improve.

Capture a defensible baseline

• Qualified inquiries, pipeline contribution, and conversion rate by landing page.
• Organic clicks, impressions, ranking topics, indexed URLs, and valuable backlinks.
• Top user tasks and where analytics, interviews, or support requests show friction.
• Publishing lead time, duplicated effort, support burden, and recurring platform incidents.
• Accessibility, security, privacy, performance, and integration risks already known.

Then write three to five outcome statements. “Make navigation easier” is a feature intention. “Increase the share of qualified visitors who reach the correct service and begin a project inquiry” is a measurable outcome.

2. Establish governance before discovery expands the scope

Complex website projects rarely fail because nobody had an opinion. They fail because the decision path was unclear. Name an accountable executive sponsor, a day-to-day product owner, subject-matter reviewers, technical owners, and the person who can accept or reject content.

3. Replace assumptions with discovery inputs

A useful discovery phase is evidence collection, not a ceremonial kickoff. Interview a small, deliberate mix of buyers, customers, sales staff, service owners, support staff, executives, and technical stakeholders. Review search behavior, sales objections, support themes, analytics, the content inventory, and competing alternatives.

End discovery with explicit decisions: priority audiences, top tasks, positioning, content gaps, platform constraints, measurement requirements, and risks that need testing. A pile of workshop notes is not a discovery deliverable.

4. Separate business, user, content, and technical requirements

Requirements are easier to evaluate when they explain the need and the acceptance condition. “Integrate the CRM” is incomplete. Define which forms, fields, consent records, routing rules, campaign values, failure alerts, and lifecycle stages must pass between systems.

Classify each requirement as must-have, should-have, or later. Identify its owner, dependency, and acceptance test. Typical requirement groups include:

• Audience: tasks, journeys, languages, devices, and accessibility needs.
• Content: types, fields, relationships, permissions, review states, and retention.
• Marketing: landing pages, attribution, consent, experiments, and campaign governance.
• Technology: CMS, identity, CRM, search, APIs, hosting, backup, and deployment.
• Risk: privacy, security, accessibility, regulatory review, and business continuity.
• Operations: roles, training, service levels, maintenance, and ownership.

5. Treat content as a migration program

Every existing URL needs a disposition before launch: keep, improve, combine, redirect, archive, or remove. Inventory the current URL, page purpose, audience, owner, traffic, conversions, backlinks, target query, freshness, legal requirement, and proposed destination.

Design the content model before writing pages. Define reusable types—service, industry, case study, person, insight, location—and the fields and relationships each needs. That improves consistency, structured data, internal linking, governance, and future redesigns.

6. Make migration requirements part of the build

SEO cannot be “added” the week before launch. The URL structure, rendering approach, navigation, page templates, canonicals, structured data, redirects, sitemap generation, analytics, and staging controls all affect what search engines can understand.

Baseline the current site before changing it and give the redirect map an owner. For the operational sequence, use the SEO migration checklist.

7. Compare partners on the work behind the deliverables

Two proposals can both say “strategy, design, development, SEO” while containing very different amounts of investigation, iteration, content work, quality assurance, migration support, and post-launch responsibility.

Questions worth asking

1. What decisions will discovery produce, and what inputs do you need from us?
2. Who performs each discipline, and who remains accountable throughout the project?
3. How are content migration, redirects, accessibility, integrations, analytics, and quality assurance scoped?
4. What is explicitly excluded, assumed, or dependent on our team?
5. How are changes estimated and approved?
6. What happens between code completion and a stable launch?
7. What evidence can you share, and which claims remain directional?

8. Build a gated schedule, not a launch-date fantasy

A responsible schedule has decision gates and dependencies. Common phases are alignment, discovery, architecture, content, design, development, integration, migration, quality assurance, launch, and stabilization. Some overlap is healthy; pretending every stream can run in parallel is not.

Track client-side responsibilities as carefully as agency work. Executive review, access to subject-matter experts, legal approval, content production, integration credentials, and procurement frequently control the critical path.

9. Budget for uncertainty and ownership

Reserve capacity for content remediation, integration surprises, stakeholder change, migration cleanup, and post-launch stabilization. Separate the build investment from recurring hosting, licenses, maintenance, analytics, content, and optimization. The website budget guide provides planning bands and comparison questions.

10. Define launch acceptance before launch week

A site is ready when named owners accept agreed criteria—not when the homepage “looks done.” Your launch checklist should cover:

• Approved content, metadata, legal text, and media rights.
• Keyboard use, labels, focus behavior, contrast, zoom, and representative assistive-technology checks.
• Responsive behavior, browser coverage, forms, integrations, error handling, and email delivery.
• Redirects, canonicals, robots directives, sitemap, structured data, and analytics events.
• Performance budgets, security headers, access controls, backups, recovery, and monitoring.
• DNS plan, rollback authority, launch communications, and first-week support ownership.

11. Measure stabilization before optimization

For the first days and weeks, monitor whether the new platform is working as intended: uptime, error rates, form delivery, integration failures, crawl behavior, indexation, redirects, analytics continuity, and real user feedback. Only then interpret longer-term changes in acquisition and conversion.

Review performance at 30, 60, and 90 days against the baseline. Separate branded from non-branded search, raw leads from qualified opportunities, and seasonality from redesign impact. Record what changed so future analysis does not rely on memory.