How to Write a Website Redesign Brief for an Agency

A strong website redesign brief gives an agency enough context to make sound decisions before visual concepts or estimates begin. It should explain why the site needs to change, who it serves, what success means, which systems and content are involved, and where risk must be controlled.

The most useful brief is not a long wish list. It is a decision document that connects business goals, user needs, content, technology, search visibility, measurement, and launch planning. It should also make trade-offs visible—for example, whether the priority is faster publishing, improved conversion, a CMS change, stronger accessibility, or a shorter delivery timeline.

This guide shows what to include and how to distinguish essential requirements from assumptions that should be investigated during discovery.

What a website redesign brief should accomplish

Your brief should help an agency answer five practical questions:

• What is changing, and why now?
• Which audiences, journeys, and business outcomes matter most?
• What must be preserved during the redesign?
• What constraints affect scope, technology, content, or timing?
• How will the team decide whether the launch worked?

It should not attempt to prescribe every page layout or technical solution. A brief provides direction; discovery, research, audits, and technical planning determine the appropriate implementation.

1. Start with the business context

Open with a concise description of the organization, its market, and the role the website plays in the business. Include the products or services the site supports, the primary geographic markets, and the internal teams that depend on it.

Then explain the reason for the redesign. Common triggers include an outdated user experience, a confusing information architecture, inconsistent branding, poor mobile performance, limited CMS flexibility, weak lead quality, or a merger that requires a unified digital presence.

Be specific about the problem rather than writing that the site needs to feel “more modern.” For example:

• Prospective buyers cannot find implementation information without contacting sales.
• Marketing cannot create or update landing pages without developer support.
• Organic traffic is concentrated on legacy URLs with unclear ownership.
• The current navigation reflects internal departments rather than customer tasks.

If multiple stakeholders have different expectations, name them. A redesign involving marketing, sales, product, customer support, legal, and IT needs an explicit decision-making process.

2. Define audiences and priority journeys

Describe the audiences the site must serve and rank them by importance. B2B sites often have several roles involved in one buying decision, such as an executive sponsor, technical evaluator, procurement contact, or day-to-day user.

For each priority audience, summarize:

• Their likely need or question.
• Their level of familiarity with the company and category.
• The action the business wants them to take.
• Information that may reduce hesitation.
• Any accessibility, language, device, or compliance considerations.

Identify the journeys that matter most. These might include evaluating a service, requesting a consultation, finding documentation, comparing solutions, locating support, or downloading a resource. Journey descriptions are more useful than vague instructions such as “make the site easier to use.”

3. Summarize the current-site audit

A redesign brief should include known evidence about the existing site, while making clear what still needs validation. Useful inputs include analytics trends, conversion data, search performance, user feedback, support questions, sales objections, usability findings, accessibility issues, and technical limitations.

Organize findings by category:

Do not treat every analytics pattern as a diagnosis. A high exit rate, for example, may indicate a problem—or a successful completion of a task. Include the evidence and let the agency investigate the cause.

4. Set measurable redesign objectives

Translate business concerns into objectives that can guide prioritization. A useful objective states the desired change, the relevant audience or journey, and how progress will be evaluated.

Examples include:

• Help qualified prospects understand the service offering and submit more complete inquiries.
• Enable the marketing team to publish approved pages without routine engineering assistance.
• Reduce the number of steps required to reach high-priority information on mobile devices.
• Protect valuable organic landing pages while improving the structure of new content.
• Establish reliable measurement for forms, calls, downloads, and key navigation actions.

Separate outcomes from deliverables. “Launch a new website” is a deliverable. “Make product evaluation easier for technical buyers” is an outcome. Both belong in the brief, but they serve different purposes.

5. Describe scope, exclusions, and trade-offs

State what the redesign is expected to include and what is outside the current engagement. Scope may cover discovery, content strategy, UX architecture, visual design, copywriting, development, CMS configuration, migration, SEO implementation, analytics, quality assurance, training, and post-launch monitoring.

Include a preliminary page or template inventory if one exists. Grouping pages by template is often more useful than listing every URL at the beginning. For example, the site may need service templates, industry pages, resource articles, case studies, location pages, and utility pages.

Also document likely trade-offs:

• A new CMS may improve publishing flexibility but require migration and training.
• A compressed timeline may require fewer custom templates or phased content work.
• A highly flexible design system may increase implementation complexity.
• Rewriting every page may improve consistency but expand review and approval time.
• A visual change that removes text or alters page structure may affect search performance.

Clear exclusions prevent assumptions from becoming late-stage scope disputes.

6. Include content and CMS requirements

Content is one of the largest sources of redesign risk. Explain who owns content decisions, whether existing copy will be audited or rewritten, which content types need migration, and how subject-matter experts will participate.

Ask the agency to account for:

• Content inventory, classification, and retention rules.
• Page ownership and approval responsibilities.
• Reusable content components and structured fields.
• Authoring workflows, permissions, versioning, and publishing controls.
• Media libraries, downloadable files, and accessibility requirements.
• Content that should be redirected, consolidated, archived, or removed.

Describe the CMS environment, including the current platform, hosting arrangement, integrations, and known limitations. If the platform is undecided, state the capabilities the business needs rather than naming a preferred technology without evaluation.

7. Make SEO migration a required workstream

A redesign can improve usability while damaging search visibility if URL and metadata decisions are handled too late. The brief should explicitly require an SEO migration plan, not simply mention SEO as a launch task.

At minimum, ask for:

• A crawl and inventory of existing indexable URLs.
• Mapping from old URLs to relevant new URLs.
• Redirect rules for changed, consolidated, and removed pages.
• Review of canonicals, robots directives, XML sitemaps, and indexation controls.
• Preservation or intentional revision of title tags, meta descriptions, headings, and structured data.
• Assessment of internal links, image metadata, pagination, and faceted or filtered URLs where relevant.
• Pre-launch and post-launch validation in search tools and analytics platforms.

Redirects should point users and search engines to the closest relevant destination, not automatically to the homepage. Canonical and schema changes should also be documented so the team can distinguish intentional improvements from accidental omissions.

For related planning considerations, see the website redesign checklist and the guidance on building a website redesign timeline.

8. Define analytics and measurement requirements

Document the current analytics tools, tag-management setup, consent requirements, CRM connections, and reporting expectations. A redesign should not create a measurement gap between the old and new site.

List the actions that matter, such as form submissions, phone clicks, appointment requests, downloads, video engagement, account actions, or qualified lead milestones. Clarify which events must be retained for trend comparisons and which new interactions should be added.

Include ownership and validation responsibilities. Someone should confirm that tracking works in staging and production, that consent behavior is correct, and that the data reaches the systems used by marketing, sales, and leadership.

9. Specify design, accessibility, and technical expectations

Explain the brand standards, visual constraints, and design-system needs without prescribing the final creative solution. If the organization has existing brand assets, provide them along with rules for typography, color, imagery, motion, and usage.

Accessibility should be a requirement from the beginning, not a final inspection. Note expectations for keyboard navigation, focus states, semantic structure, color contrast, forms, alternative text, captions, responsive behavior, and assistive-technology compatibility. The applicable legal and organizational requirements should be reviewed by the appropriate internal stakeholders.

Technical requirements may include performance targets, responsive breakpoints, browser support, security review, integrations, API dependencies, environments, deployment controls, backups, and ongoing maintenance. If technical requirements are unknown, identify them as discovery questions rather than inventing specifications.

For a broader view of how visual systems and user-facing design connect, you can reference design services and disciplines as part of your internal planning.

10. Explain governance, schedule, and approvals

Include the target launch window, fixed business dates, dependencies, review cycles, and internal availability. A realistic schedule depends not only on agency production but also on stakeholder response, content readiness, technical access, legal review, and migration preparation.

Identify:

• The final decision-maker.
• Day-to-day project owner.
• Subject-matter experts and reviewers.
• Technical and security contacts.
• Legal, compliance, and accessibility reviewers.
• Who approves content, design, SEO, analytics, and launch readiness.

Set expectations for feedback format and turnaround time. Too many uncoordinated reviewers can create contradictory direction; too few can create approval delays or overlooked risks.

11. Require launch and post-launch monitoring

Launch is a transition, not the end of the project. Your brief should request a launch plan that covers backups, deployment responsibilities, redirect activation, DNS or hosting coordination, analytics checks, form testing, crawl validation, error monitoring, and rollback criteria.

Post-launch monitoring should include technical errors, indexation, redirects, rankings or organic landing-page performance, conversions, page speed, accessibility issues, and user feedback. The monitoring period should be agreed in advance, along with who investigates problems and how fixes are prioritized.

A phased launch may be appropriate when the site is large, the CMS is changing, or content and migration risks are substantial. The brief can ask the agency to recommend a release strategy rather than assuming that every page must launch at once.

Website redesign brief checklist

Before sending the brief, confirm that it answers the following:

• Why is the redesign needed, and what evidence supports it?
• Who are the priority audiences and journeys?
• What outcomes and measures define success?
• What pages, templates, content types, and systems are in scope?
• What is explicitly excluded?
• What must be preserved for SEO, analytics, accessibility, and operations?
• Who owns decisions, content, approvals, and technical access?
• What constraints affect budget, timing, platform, or integrations?
• How will redirects, canonicals, schema, analytics, and QA be handled?
• What happens during launch and after release?

How to use the brief when evaluating agency responses

Give each agency the same core brief and compare responses against the same criteria. Look for evidence that the proposed process connects audit findings to scope, UX to content, design to development, and migration to post-launch monitoring.

Be cautious when a proposal focuses almost entirely on visual direction but says little about content ownership, CMS architecture, redirects, analytics, testing, or launch support. Those omissions can create substantial work after the design phase.

Also compare assumptions. A lower initial estimate may exclude content migration, SEO mapping, analytics configuration, accessibility remediation, or post-launch support. Ask each agency to identify dependencies, open questions, optional phases, and risks before selecting a plan.

Final takeaway

The best website redesign brief creates alignment without pretending every answer is known. Give the agency clear business context, audience priorities, evidence from the current site, measurable objectives, scope boundaries, content and CMS requirements, SEO safeguards, analytics needs, technical expectations, governance details, and launch criteria. For commercial planning and implementation support, visit the website redesign service page.