A website redesign SEO checklist is a control document used by marketing, SEO and development teams to protect organic visibility before a redesigned website goes live.
It helps the team confirm that important URLs, redirects, content, internal links, metadata, indexation rules, tracking and conversion paths have been preserved or improved during the redesign. Without it, a site can launch looking better while quietly losing search visibility, leads or ecommerce revenue.
This checklist is for businesses planning a redesign, rebuilding on a new CMS, changing templates, refreshing content or relaunching an ecommerce site. It matters most when the current website already receives organic traffic, enquiries, bookings or online sales.
For higher-risk redesigns, involve a technical SEO South Africa specialist before structure, navigation and URL decisions are finalised.
Quick answer
A website redesign SEO checklist helps you confirm that the redesigned site is still crawlable, indexable, internally linked, correctly redirected and aligned to the same or better search intent as the old site.
At minimum, the checklist should cover:
- current site crawl and URL inventory;
- important organic landing pages;
- URL changes and redirect mapping;
- navigation and internal links;
- retained, rewritten or removed content;
- title tags, H1s, canonicals and indexation rules;
- staging crawl checks;
- analytics, forms and conversion tracking;
- live-site crawl checks after launch;
- Search Console, organic traffic and conversion monitoring after launch.
This is not only an SEO task. It should be shared between the marketing team, developer, designer, content team and business owner so SEO risk is considered before decisions become expensive to reverse.
How this differs from similar checklists
A website redesign SEO checklist is often confused with a migration checklist, technical SEO audit, launch QA checklist or general redesign checklist. They overlap, but they do different jobs.
| Checklist type | Main focus | When to use it |
|---|---|---|
| Website redesign SEO checklist | Protecting SEO during visual, structural, content or template changes | When the website is being redesigned, refreshed or rebuilt |
| Website migration checklist | Managing major moves such as domain, CMS, platform, protocol or URL structure changes | When the site is moving location, platform or URL system |
| Technical SEO audit | Diagnosing crawl, indexation, performance and technical issues | Before a redesign, after a traffic drop or during SEO planning |
| Launch QA checklist | Checking that the new site functions correctly | Immediately before launch across links, forms, tracking and functionality |
| General redesign checklist | Managing design, UX, brand, development and content tasks | Throughout the redesign project |
A redesign SEO checklist sits between strategy and launch QA. It does not replace a full website technical audit, but it helps prevent common redesign mistakes before they reach the live site.
Why this matters
A redesign can change the signals search engines use to understand your website.
Even when the domain stays the same, the redesign may change URLs, menus, page copy, headings, metadata, templates, internal links, page speed, structured data, canonical tags and indexation rules. Those changes can affect how search engines crawl, process and rank the site.
The risk is not that redesigns are bad for SEO. The risk is that SEO decisions are often made accidentally.
Common examples include:
- A high-performing service page is removed because it does not fit the new navigation.
- Old service URLs are redirected to the homepage instead of the closest replacement page.
- Ecommerce category copy is removed because the new design prioritises product tiles.
- A staging noindex tag is pushed live and blocks important pages from being indexed.
- Canonical tags point to the wrong version of a page after template changes.
- Internal links to important commercial pages disappear from the homepage, footer or resource pages.
- Enquiry form tracking breaks, so the business cannot see whether organic leads have dropped.
A typical South African service business might redesign its site to simplify its menu, remove older service pages and replace detailed copy with short brand-led messaging. The new site may look cleaner, but if those removed pages were bringing organic enquiries, the business has removed part of its search acquisition path.
A good checklist reduces this risk. It helps the team protect what already works while improving the site.
Common causes or scenarios
Website redesign SEO problems usually come from normal project decisions, not obviously bad SEO practice.
URL changes without a redirect plan
A redesigned site often introduces cleaner URLs, new page names or a simplified structure. That may be useful, but every changed URL needs a destination.
A common mistake is redirecting old pages to the homepage because it feels simple. For example, an old page such as /services/seo-audit/ might be redirected to / instead of the new audit page. That weakens relevance for users and search engines.
Better approach: map each important old URL to the closest live equivalent before launch. If there is no equivalent, decide whether the page should be recreated, merged or intentionally removed.
Use a dedicated SEO redirect mapping process if URLs are changing.
Important pages are removed during simplification
Redesigns often reduce the number of pages to make the site cleaner. That can help users, but it can also remove pages that were doing important SEO work.
Before deleting or merging a page, check whether it receives organic traffic, ranks for useful queries, has backlinks, supports a service or product journey, answers a distinct search intent, or helps users move toward a conversion.
A page with weak design may still have strong search value. In that case, improve it rather than remove it.
Navigation changes reduce internal links
A new menu may look simpler but make important pages harder to reach.
If commercial pages, category pages or resource pages lose links from the homepage, menu, footer, breadcrumbs or related content, their crawl paths and internal authority can weaken.
This is especially important for service businesses and ecommerce sites where category, product and commercial pages need clear internal support.
Metadata is overwritten by new templates
During a redesign, title tags, meta descriptions, H1s and canonical tags may be replaced by CMS defaults.
Examples include every page title becoming only the company name, blog posts inheriting the same meta description, service pages losing their unique H1s, canonical tags pointing to the staging URL, or product pages using duplicate template metadata.
These issues are avoidable if priority pages are checked before launch.
Content is cut too aggressively
Redesign projects often favour shorter pages. Shorter content is not automatically bad, but cutting useful explanation can weaken page relevance.
For example, a service page may lose its sections on who the service is for, what is included, how the process works and when a business should get help. The page may look cleaner, but it may no longer answer the buyer’s questions.
For ecommerce sites, removing category descriptions, buying guidance or internal links can reduce the page’s ability to target category-level search intent.
If you are redesigning an online store, involve an ecommerce SEO consultant before changing category, product, filter or pagination logic.
Staging settings are pushed live
Staging sites often use controls that should not appear on the live site. These may include password protection, blocked robots.txt rules, noindex tags or staging canonicals.
A serious redesign issue can happen when a staging noindex tag is pushed live. The site may look fine to users, but important pages may be telling search engines not to index them.
That is why pre-launch and post-launch crawling are both essential.
How to assess the issue
Start by separating redesign SEO checks into three priority levels. Not every issue carries the same risk. Some problems should stop a launch. Others should be fixed before launch if possible. Others can be monitored after launch.
Launch blockers
Launch blockers are issues that can cause serious visibility, crawlability or tracking problems if the site goes live with them.
Treat these as launch blockers:
- important pages are blocked by robots.txt;
- important pages have noindex tags;
- priority old URLs do not redirect;
- redirects point to irrelevant pages;
- canonical tags point to staging or incorrect URLs;
- the live site cannot be crawled;
- important pages return 404, 500 or other error responses;
- analytics, enquiry forms, checkout or conversion tracking does not work;
- the XML sitemap contains staging, broken or non-indexable URLs.
If any of these are present, fix them before launch.
High-priority pre-launch checks
These checks may not always stop a launch, but they can weaken performance if ignored.
Review whether important organic landing pages still exist, whether service and category pages still answer the right search intent, and whether page titles, H1s and meta descriptions are unique and relevant.
Also check whether internal links still support key commercial pages, structured data remains valid, mobile templates are usable, and ecommerce filters, pagination and category pages behave correctly.
These checks should happen on staging while fixes are still easier to make.
Monitor after launch
Some issues only become clear once the redesigned site is live and data starts coming in.
Monitor Search Console coverage, organic landing page traffic, priority keyword movement, crawl errors, redirect errors, organic conversions, Core Web Vitals and the performance of pages that were merged, rewritten or redirected.
Post-launch monitoring helps the team separate normal redesign fluctuation from serious technical issues.
Recommended fixes or decisions
The checklist should lead to clear decisions before launch, not a long list of unresolved notes.
Decide what must stay
Keep URLs, content and internal links that already support organic visibility, leads, sales or important user journeys unless there is a strong reason to change them.
This does not mean the old site structure must be preserved exactly. It means valuable search assets should be understood before they are redesigned.
Decide what can change
Some pages should be improved, consolidated or moved. That is normal during a redesign.
The key is to make each change deliberately. A page should not disappear because it was forgotten during wireframing. A URL should not change because a new naming convention looks neater. Important copy should not be removed because the first design draft has less space.
Decide what needs redirect mapping
Any changed or removed URL needs a clear redirect decision. The replacement page should match the old page as closely as possible in topic and user intent.
A redirect map is especially important where service pages, category pages, product pages, location pages, resources or blog posts have earned traffic or backlinks.
Decide what needs expert review
Not every redesign needs a full technical SEO review. But if the site already drives organic leads or sales, or if URLs, templates, CMS logic, ecommerce structures or core content are changing, a specialist review is usually safer than a last-minute check.
The cost of SEO input is usually lower before launch than after a visibility drop.
Complete website redesign SEO checklist
Use this checklist as a working project document. It can be copied into a redesign brief, pre-launch QA sheet or shared task board.
Before redesign
| Status | Priority | Check | Owner |
|---|---|---|---|
| ☐ | Launch blocker | Crawl the current live site and export all URLs. | SEO / Developer |
| ☐ | High priority | Identify organic landing pages that bring traffic, leads or sales. | Marketing / SEO |
| ☐ | High priority | Export Search Console page and query data. | SEO |
| ☐ | High priority | Identify URLs with backlinks. | SEO |
| ☐ | High priority | Mark priority service, category, product and location pages. | Marketing / SEO |
| ☐ | High priority | Decide which pages will be kept, improved, merged, redirected or removed. | Marketing / SEO |
| ☐ | High priority | Export current title tags, H1s, meta descriptions and canonicals. | SEO / Developer |
| ☐ | High priority | Document current navigation and key internal links. | SEO / UX |
| ☐ | High priority | Confirm whether URL structure will change. | Developer / SEO |
| ☐ | High priority | Create redirect mapping requirements if URLs are changing. | SEO / Developer |
During staging
| Status | Priority | Check | Owner |
|---|---|---|---|
| ☐ | Launch blocker | Crawl the staging site. | SEO / Developer |
| ☐ | Launch blocker | Check that important pages are not noindexed by mistake. | SEO / Developer |
| ☐ | Launch blocker | Check that canonicals do not point to staging URLs. | SEO / Developer |
| ☐ | Launch blocker | Confirm robots.txt will not block important live pages. | Developer / SEO |
| ☐ | Launch blocker | Test priority redirects before launch where possible. | Developer / SEO |
| ☐ | High priority | Confirm priority pages still exist on the redesigned site. | Marketing / SEO |
| ☐ | High priority | Review whether important content has been removed. | Content / SEO |
| ☐ | High priority | Check title tags, H1s and meta descriptions on priority pages. | SEO / Content |
| ☐ | High priority | Check internal links to commercial, category and resource pages. | SEO / UX |
| ☐ | High priority | Validate XML sitemap logic. | Developer / SEO |
| ☐ | High priority | Check structured data against visible page content. | SEO / Developer |
| ☐ | High priority | Test mobile usability and key templates. | UX / Developer |
| ☐ | High priority | Test forms, checkout, booking or enquiry paths. | Developer / Marketing |
| ☐ | High priority | Confirm analytics and conversion tracking are ready. | Marketing / Developer |
Launch day
| Status | Priority | Check | Owner |
|---|---|---|---|
| ☐ | Launch blocker | Crawl the live site immediately after launch. | SEO / Developer |
| ☐ | Launch blocker | Test priority old URLs and redirects. | SEO / Developer |
| ☐ | Launch blocker | Confirm important pages return 200 status codes. | SEO / Developer |
| ☐ | Launch blocker | Confirm important pages are indexable. | SEO |
| ☐ | Launch blocker | Check live robots.txt. | Developer / SEO |
| ☐ | Launch blocker | Check live canonical tags. | SEO / Developer |
| ☐ | Launch blocker | Test enquiry forms, checkout or conversion paths. | Marketing / Developer |
| ☐ | High priority | Submit or refresh XML sitemap. | SEO |
| ☐ | High priority | Check Search Console for urgent crawl or indexing issues. | SEO |
| ☐ | High priority | Confirm analytics and conversion events are recording. | Marketing / Developer |
After launch
| Status | Priority | Check | Owner |
|---|---|---|---|
| ☐ | Monitor after launch | Review Search Console coverage and indexing changes. | SEO |
| ☐ | Monitor after launch | Monitor organic landing page traffic. | Marketing / SEO |
| ☐ | Monitor after launch | Monitor leads, enquiries, bookings or ecommerce revenue from organic search. | Marketing |
| ☐ | Monitor after launch | Check crawl errors and redirect errors. | SEO / Developer |
| ☐ | Monitor after launch | Review priority keyword movement. | SEO |
| ☐ | Monitor after launch | Check Core Web Vitals and page speed trends. | SEO / Developer |
| ☐ | Monitor after launch | Review performance of merged, rewritten or redirected pages. | SEO / Content |
| ☐ | Monitor after launch | Prioritise fixes based on visibility, conversion and crawl impact. | SEO / Marketing |
When to get expert help
A DIY checklist is usually enough when the redesign is small, URLs are staying the same, the site has limited organic traffic and the changes are mostly visual.
You should consider a technical SEO review when:
- the site already generates leads or sales from organic search;
- important URLs are changing;
- pages are being merged or removed;
- the CMS or ecommerce platform is changing;
- the site has many indexed pages;
- the redesign affects ecommerce category, product or filter pages;
- developers are rebuilding templates;
- organic visibility has dropped before;
- you are unsure which pages carry SEO value.
In those cases, expert input can help identify risk before launch, not after traffic has dropped.
The role of a technical SEO review is not to slow the redesign down. It is to help the team make clearer decisions about structure, redirects, crawlability, indexation, internal links and post-launch checks.
Related resources
Choose the next resource based on the type of redesign risk you are dealing with.
If the concern is crawlability, indexation, internal linking or site structure, start with technical SEO South Africa. If the redesigned site has already launched and visibility has changed, a website technical audit can help identify what changed. If URLs are being removed, renamed or consolidated, plan the move with SEO redirect mapping before launch. For online stores, speak to an ecommerce SEO consultant before changing category, product, filter or pagination logic.
For more planning guides, visit SEO resources South Africa.
Next step
Use this checklist internally if your redesign is mostly visual, your URLs are staying the same and organic search is not a major acquisition channel.
If the redesign changes URLs, templates, navigation, content, CMS, ecommerce structure or pages that already bring in organic leads or sales, review the SEO risks before the site goes live.
The earlier SEO is involved, the easier the fixes usually are. Once a redesigned site is live, the same issue can become harder to diagnose, harder to reverse and more expensive to recover from.
Before your redesigned website goes live, discuss a technical SEO review so the team can check redirects, crawlability, indexation, internal links and priority pages while fixes are still practical.