How to Write an SEO Brief for a Website Redesign

A website redesign brief should explain what the new site must preserve, what it may change and how the team will know the launch works. For a small UK business, a beautiful new design can still be a poor result if established service pages disappear, useful explanations are cut or customers cannot complete an enquiry. SEO considerations are therefore not a final plugin check; they belong alongside content, navigation, technical delivery and the commercial purpose from the beginning. A practical brief gives designers and developers enough information to make responsible decisions without pretending that search rankings can be guaranteed by a layout or URL convention.

State the business task and design boundaries

Before listing technical requirements, describe what the existing website helps customers do and which experiences need to improve. A service company may need clearer information about eligibility and an easier route to contact. An online shop may need product filtering that works on a phone. A publisher may need a readable technical guide layout with citations and comparison tables. Each task has different implications for information architecture and public acceptance.

Identify the pages and customer routes the redesign must preserve. Ask who owns the real service descriptions, who can approve claims and whether the business is changing its offerings at the same time. Distinguish a brand refresh from a full content restructuring. If the services remain the same, the brief should not create unnecessary new pages solely because the designer prefers a different menu label. Conversely, if the company is retiring an offering, that decision needs an editorial and navigation plan.

Include constraints such as the current CMS, hosting arrangements, available developer time, accessibility requirements and approved image assets. A brief should not demand expensive features that the client cannot operate or maintain. Set responsibilities for decisions and record which assumptions require validation. This makes the redesign feasible rather than a collection of aspirations.

Capture a trustworthy baseline of the present site

Record current important public URLs, their purpose, the content they display and the route customers use to reach them. Gather a suitable crawl, XML sitemaps, CMS records and authorised search-performance observations where available. These sources can disagree, so keep their provenance. A CMS entry marked live does not prove its public URL renders; a crawler may miss orphaned articles. Compare evidence rather than silently declaring one export complete.

Build a list of URLs that must remain or have relevant successors. Note prominent service pages, helpful guides, category destinations and contact paths. Preserve a snapshot of the old public content where authorised, especially factual sections that might be shortened in the new design. Track existing canonical signals and redirects so the new platform does not accidentally create inconsistent versions of the same page.

Use baseline traffic cautiously. A page with few search clicks can be essential for customer support. A historically high-traffic article may contain obsolete information and need review. Google's Search Console Performance documentation describes clicks, impressions and report limitations. Those measures can inform planning, but do not substitute for deciding what information customers still need.

Make content preservation an explicit requirement

Redesign briefs often focus on appearance while treating text as material that can be shortened to fit a new component. That can remove the substance making the old page useful. Specify which explanations, prerequisites, service conditions, evidence and customer actions must survive. Content can be reorganised or rewritten when it remains accurate, but should not become a vague slogan in place of a detailed answer.

Describe the role of each new component. A comparison table needs meaningful headers and responsive behaviour. A technical article may need code snippets, long headings, quotations and a properly attributed image. An FAQ must remain accessible even when displayed through an accordion. Check whether the proposed CMS supports all those elements safely, including semantic HTML and source links. A page builder demonstration using short placeholder sentences is not an adequate test of real publishing requirements.

Set an approval process for changed claims. A designer is not automatically authorised to rewrite regulated advice or assert a new office location. Where existing content contains errors, correct it through the responsible subject owner instead of copying it unchanged. Distinguish genuine content improvements from accidental loss during migration.

Plan information architecture and navigation with readers

A menu should reflect actual services and questions, not merely the departments inside the business. Identify primary destinations and sensible groupings, then test whether someone can find an answer without understanding the organisation's internal vocabulary. A large site may need categories and breadcrumbs; a small one may benefit from a shorter menu with contextual links. There is no universal click-count ranking formula that replaces real navigation testing.

Document where important internal links should appear. A service overview might link to a specialist guide explaining a prerequisite; an article may link to the applicable service page where help is genuinely relevant. Avoid creating dozens of keyword-focused footer links that add clutter without serving readers. Google's link best practices describe normal crawlable anchors, not a mandate to repeat every target phrase.

Test the navigation with real content and different devices. Sticky headers, collapsible menus and anchor jumps can create obstacles even when the sitemap appears logical. Ensure keyboard operation and visible focus. The brief should identify these acceptance conditions before the frontend is built.

Decide whether established URLs actually need to change

A redesign does not necessarily require new URL paths. Established descriptive URLs may appear in bookmarks, external references and customer documentation. If their content identity remains appropriate, retaining them can avoid needless redirect complexity. When a real migration requires moves, create an old-to-new mapping based on reader relevance rather than automated string similarity.

For each changed URL, decide whether the resource moves, merges or retires. Redirect to a genuine successor where one exists, not indiscriminately to the homepage. Update key internal links, canonical declarations and sitemaps. Test actual HTTP responses for important old and new paths and avoid chains or loops. Google's site-move guidance documents these steps while making no fixed promise about future rankings.

Identify who owns server redirects and who signs off content destinations. A URL mapping is partly a technical implementation and partly an editorial decision. A designer may know the new layout but not whether the replacement guide accurately answers the old link's question.

Specify indexability and rendering requirements

The new site should deliver accessible public responses for content intended to be discoverable. Define expected canonical hostnames, redirect conventions, robots behaviour, sitemap generation and indexing directives. Development environments may need restrictions, but those restrictions must not leak into production. Sensitive records require proper authentication, not robots.txt.

If the site uses JavaScript extensively, verify that essential main content, metadata and navigational links are available in the rendered output. A correct CMS database value cannot guarantee that a cache or frontend component displays the latest article. Inspect actual public HTML and representative rendering states. Include long titles, missing optional images and nested article sections in component regression tests.

Keep technical success separate from search outcome. A publicly accessible and correctly canonicalised URL is directly testable. Whether Google indexes it, selects it for a particular query or shows a desired title link remains an external decision.

Design mobile and accessible interaction as acceptance criteria

A responsive layout should preserve useful content and essential actions on narrow screens. Specify representative tests around 320, 375 and 768 CSS pixels as practical samples, supplemented by zoom and actual devices where available. Check long navigation labels, comparison tables, captions, sticky banners and contact forms. The viewport meta tag is a foundation, not proof that the complete experience works.

Use semantic headings, meaningful link labels, appropriate image alt text and properly associated form fields. Test keyboard access and visible focus rather than relying solely on a visual review. The W3C WAI tutorials provide relevant accessible design patterns. An automated score can identify some problems, but cannot verify every human task or whether the company receives a valid enquiry.

Specify the handling of errors and success states. A contact form may display a confirmation while its backend fails. Use authorised test data to confirm the full workflow. Do not collect real customer secrets during test submissions.

Prepare a launch and rollback plan

Identify the deployment owner, content sign-off authority and the person responsible for public verification. Agree which tests must pass before launch and which observations can be monitored afterwards. Have a plan for restoring essential functionality if a global component or redirect rule fails. The launch process should identify any unresolved exceptions instead of hiding them behind a generic completion status.

Check priority URLs and representative templates immediately after release. Compare old-to-new mappings, content presence, canonical signals, navigation, media attribution, forms and mobile behaviour. Confirm that private editorial notes do not appear publicly. A successful production database update and read-back only verify that data was stored; browser rendering, image loading and end-to-end customer actions are separate tests.

Use post-launch observations without claiming guaranteed gains

Record the actual launch date and important changes. Search Console can help monitor relevant page and query groups, but demand, competition and search presentation may change at the same time. Do not promise a specific recovery date or attribute every traffic movement to the redesign. Use a dated release log to distinguish confirmed technical incidents from possible external influences.

Review the new site for missing content and usability defects before chasing small position changes. A service form that does not submit is an immediate business issue even if organic clicks remain stable. A missing redirect may affect people following established links. Fix reproduced failures at their root and retest the public result.

A strong redesign brief gives a small team a common definition of success: the right pages and facts preserved, necessary changes mapped, technical behaviour specified, usable components built and the public website verified. Design quality, SEO eligibility and business usefulness support one another, but none is proved simply by a launch announcement or a green dashboard. A brief that makes responsibilities and evidence explicit prevents expensive surprises after the new site is live.