Website Redesign: Write a Brief That Protects SEO, Conversion and Measurement
A website redesign brief should make decisions before design work begins: what must remain available, what visitors need to understand more easily, which actions must still be measured, and how French, Arabic, and English versions will remain useful localised experiences. The goal is a testable plan for SEO, conversion, tracking, and multilingual content—not a list of visual preferences.
The supplied plan associates the French query “refonte site web” with volume 10 and commercial/informational intent: Ahrefs Morocco estimate, 22 October 2026. It is a search-demand estimate, not a traffic, ranking, enquiry, or revenue forecast.
Start with the decision the new site must support
A redesign brief is not a collection of colours, templates, and competitor screenshots. It explains the problem behind the change. Without that discipline, a polished site can make an offer less clear, remove a useful page, break a form journey, or publish an incomplete language version.
Write one or two jobs the website should support better: explaining an offer, helping a buyer assess fit, arranging a conversation, or sharing evidence. Name the audiences, offers, languages, approvers, and desired next action.
What a usable redesign brief contains
A short brief can be effective if it assigns decisions, owners, and verification.
| Brief component | Decision | Evidence or output |
|---|---|---|
| Goal and audiences | Which journey needs improvement? | Priorities, stakeholders, acceptance criteria |
| Inventory | What is retained, merged, removed, or created? | URLs, content, media, forms, dependencies |
| Information architecture | How does a visitor reach the offer and next step? | Navigation, internal links, mobile journey |
| Migration | What happens to each meaningful old address? | Old-to-new URL map, redirect rules, tests |
| Languages | What must be useful in each version? | Localised content plan and reviewer |
| Measurement | Which actions inform a decision? | Event plan, validation, deduplication rule |
| Launch acceptance | How is delivery checked? | Test cases, owner, sign-off date |
Control URL and architecture changes
A visual redesign that keeps existing URLs still needs checks for internal links, canonical URLs, indexability directives, mobile rendering, and errors. If addresses change, the brief should treat the work as a controlled migration.
Map each relevant old URL
Collect URLs from the CMS, sitemap, search tools, analytics, and campaign destinations. For every important old page, select the most relevant new destination. A former service page should reach an equivalent or genuinely consolidated page. Sending many removed pages to the homepage is not a substitute for a mapping decision.
Google recommends server-side permanent redirects where technically possible, including HTTP 301 and 308. Its site-move guidance also advises avoiding redirect chains, updating internal links and canonical annotations, testing redirects, and submitting an updated sitemap. Keep the URL map: it is both a technical specification and an acceptance-test list.
Specify launch tests before the launch window
In staging, test a priority sample of old URLs for status code, final destination, canonical URL, visible content, navigation, and forms. If the architecture changed, submit the new sitemap and review crawl errors after publication. Google notes that visibility may fluctuate temporarily during a move; this is a reason to monitor, not an outcome to promise.
A structured SEO service can turn the inventory and checks into priorities, but the site owner still needs to validate the redirects and published content.
Make every language version complete
A language selector is not localisation. Each version needs a clear offer, navigation, CTA, confirmation, and relevant examples. Give each language an editorial owner to check commercial meaning, terminology, dates, and calls to action. Arabic also needs review of right-to-left direction, typography, alignment, and mobile behaviour.
Where pages are genuine localised equivalents, plan hreflang with the architecture. Google states that every version should list itself and its alternatives, with reciprocal links. Its localized-page documentation covers HTML, HTTP-header, and sitemap methods. Do not label unrelated pages as alternatives merely to complete a set.
Design a decision journey, not just a CTA
For each priority page, define the sequence: recognised problem, intended audience, scope, evidence, objection, action, and next step. This makes design and copy reviewable.
Use observable acceptance tests. Can a visitor identify the offer, understand the CTA, complete necessary fields, and receive a meaningful confirmation? A dedicated experience may require a landing page service, while page priorities may require a digital strategy.
Protect measurement and test what matters
A redesign may change components, forms, confirmation routes, and third-party scripts. Write the measurement plan before rebuilding. For each action, record event name, firing condition, parameters, page, data-owning system, owner, deduplication rule, and decision supported.
Do not tag an interaction merely because it is easy to collect. Test validation errors, abandoned forms, double clicks, and declined consent so they do not appear as successful requests. Google Analytics DebugView notes that privacy controls and consent can affect visible events. Digital One Media’s Tracking & Analytics service can connect technical rules to business definitions.
Include performance and accessibility in acceptance
New layouts can add image weight, fonts, motion, and third-party code. Current Core Web Vitals cover loading, responsiveness, and visual stability through LCP, INP, and CLS. The web.dev Web Vitals guide publishes reference thresholds of 2.5 seconds, 200 milliseconds, and 0.1 at the 75th percentile, while stressing that lab tests do not replace field measurement. These are checks, not assurances for every visit.
Include keyboard navigation, heading order, contrast, field labels, understandable errors, text alternatives, visible focus, and mobile reading. W3C structures WCAG 2.2 around perceivable, operable, understandable, and robust content. The W3C WCAG overview is a practical reference; an automated tool alone cannot determine conformance.
Decide what belongs in this release
Prioritise requests by their effect on the primary journey, risk if omitted, dependencies, validation effort, and reversibility. URL migration, critical forms, data access, consent behaviour, and approved content require decisions before launch. A new animation or unapproved section can wait.
FAQ — Website redesign brief
Do we need to change every URL in a redesign?
No. Retaining a relevant address reduces migration work. When a new URL genuinely improves the architecture, document a suitable destination, use a server-side permanent redirect where possible, avoid chains, and test it.
Who should approve the brief?
A business sponsor sets priorities. Marketing and sales validate offers, content, and desired actions; technical colleagues confirm architecture, redirects, and integrations. Assign an owner for each language and one for measurement.
Can we launch before all translations are ready?
Yes, if the published scope is coherent and unfinished pages are not presented as available. Identify genuine equivalents and update language annotations reciprocally when equivalent pages are published.
How can we check whether tracking survived?
Run priority journeys in staging and after launch: submit a form, request a callback, start a meeting booking, or download a resource. Compare the observed event, parameters, and confirmation with the measurement plan, then investigate unexpected or duplicate firing.