A website redesign can change far more than colours, fonts and page layouts. It may also alter URLs, navigation, content, internal links, page templates, structured data, tracking and the way search engines access important information.
A more reliable approach is to treat SEO as part of the redesign specification rather than a final check. A project works more reliably when web development and SEO are planned together because design and development decisions can affect how pages are discovered, rendered, understood and used.
This checklist covers redesigns that retain the existing domain as well as projects involving a new CMS, changed URLs or a domain migration. Not every step applies to every project, but every decision should be made deliberately.
First Determine What the Redesign Will Change
The term “website redesign” can describe several different projects. Identifying the type of change helps define the checks required.
| Redesign type | Main SEO considerations |
| Visual redesign with unchanged URLs | Content visibility, headings, mobile layouts, internal links and performance |
| Theme or template replacement | Rendering, metadata, structured data, navigation and page-speed changes |
| CMS or platform migration | URL behaviour, status codes, canonicals, metadata, forms, tracking and redirects |
| Content restructuring | Page purpose, lost information, consolidation and internal linking |
| URL restructuring | Old-to-new mapping, permanent redirects, sitemap updates and backlink destinations |
| Domain or subdomain migration | Redirects, Search Console verification, Change of Address and prolonged monitoring |
| Combined migration and redesign | All relevant checks, with additional emphasis on testing and rollback planning |
A redesign that keeps every existing URL can still create search problems if important content disappears, navigation becomes less useful or templates introduce incorrect canonical or robots directives. Conversely, a visual change that preserves content, URLs and technical controls may require fewer migration steps.
Avoid changing the domain, CMS, URL structure, content strategy and design at the same time unless the project genuinely requires it. Separating major changes can make problems easier to identify and correct.
Assign Responsibility Before Work Begins
A redesign needs clear ownership. Without it, SEO tasks can fall between the people responsible for design, development, content and marketing.
Record who will approve:
- The final site structure
- Page removals and consolidations
- Old-to-new URL mappings
- Redirect implementation
- Page titles and descriptions
- Canonical and robots directives
- Structured data
- Analytics and conversion tracking
- Staging restrictions
- Pre-launch testing
- Launch approval
- Post-launch monitoring
- Rollback decisions
The same person does not need to perform every task. However, every task should have an identified owner, reviewer and completion status.
Create a recoverable backup of the current website and document the rollback process before deployment. A backup is useful only when the team knows what it contains, where it is stored and how the website can be restored.
Establish a Measurable Pre-Redesign Baseline
Record the current website before changing it. This creates a reference for detecting accidental losses and evaluating the new version.
The baseline should include information that matters to the website’s purpose rather than a collection of unrelated metrics.
Search and content baseline
Record:
- Indexed and non-indexed URLs reported in Search Console
- Organic landing pages
- Search queries associated with important pages
- Pages receiving meaningful organic visits
- Pages with external links
- Current title elements and meta descriptions
- H1 headings and important supporting headings
- Main page content
- Canonical URLs
- Structured data
- Hreflang annotations, if used
- Existing redirects
- XML sitemap URLs
- Image and document URLs receiving search traffic
Business and measurement baseline
Record:
- Enquiry, purchase, registration or booking actions
- Important form submissions
- Phone and email interactions where legitimately measured
- Landing pages that contribute to conversions
- Existing analytics events
- Advertising conversion tags
- Thank-you pages
- Consent settings
- Internal search tracking, if used
Technical baseline
Run a crawl of the current website and save:
- Indexable URLs
- Status codes
- Redirect chains
- Broken internal links
- Canonical targets
- Robots directives
- Page titles and descriptions
- H1 headings
- Structured data
- Image references
- Internal-link relationships
- Page depth
- Orphan URLs found through sitemaps or external data
A technical SEO audit can identify existing crawl, indexing, canonical and performance issues that should not be transferred into the redesigned website. Document known problems separately so the team does not mistake an old issue for a launch regression.
Build a Complete Content and URL Inventory
A redesign should account for every meaningful page and asset, including content that may not appear in the main navigation.
Combine information from:
- The current XML sitemap
- A crawl of the live website
- The content-management system
- Search Console
- Analytics
- Server logs where available
- Backlink data
- Paid campaign destinations
- Navigation and footer links
- Image, video and document directories
- Manually maintained landing pages
The inventory should include more than HTML pages. Record important PDFs, images, downloadable resources, videos and other files if users or search engines reach them directly.
Suggested inventory fields include:
| Field | Purpose |
| Current URL | Identifies the existing destination |
| Page type | Distinguishes services, articles, products, policies and other templates |
| Current status | Confirms whether the URL returns 200, redirects or produces an error |
| Indexability | Records canonical, robots and indexing status |
| Organic value | Notes traffic, queries and external links |
| Business purpose | Explains what the page helps users or the business accomplish |
| Redesign decision | Keep, update, move, consolidate, remove or investigate |
| New URL | Records the intended destination |
| Redirect required | Confirms whether a permanent redirect is needed |
| Content owner | Identifies responsibility |
| Approval status | Prevents unresolved pages from reaching launch |
Do not assume that a page without significant traffic has no value. It may support a customer decision, answer an essential question, receive direct visits or provide necessary legal and operational information.
Give Every Existing URL a Clear Decision
Each current URL should receive a documented decision before the redesigned site launches.
Keep
Retain the URL when the page still serves the same purpose and no structural reason requires a change. Keeping useful URLs reduces unnecessary migration work.
Update
Improve the page while retaining its URL when the subject and purpose remain substantially the same. A redesign is not a reason to replace a stable, descriptive URL merely to make it shorter.
Move
Use a new URL when the information genuinely belongs in a different structure. Map the old URL directly to the closest relevant new destination.
Consolidate
Combine pages when they serve the same need and maintaining separate destinations no longer helps the reader. Preserve the strongest useful information and redirect the retired URLs to the consolidated page.
These decisions should follow the website’s broader content strategy rather than being made only from a design mock-up.
Remove
If a page has no suitable replacement and no continuing purpose, allow it to return an appropriate 404 or 410 response. Do not redirect unrelated removed pages to the homepage merely to avoid an error status.
Investigate
Do not make a permanent decision when the page’s ownership, traffic, backlinks or business purpose remains unclear. Resolve the uncertainty before launch.
Protect the Purpose of Important Pages
A new design should not change what a page is supposed to accomplish unless that change has been intentionally approved.
For every important page, record:
- Intended audience
- Main user question or task
- Page purpose
- Essential facts
- Primary offer or subject
- Search theme
- Required evidence
- Desired next step
- Internal links
- Responsible reviewer
The redesign should preserve the distinction between homepage and service-page copy instead of forcing every page to repeat the same company-level message.
A homepage normally helps different visitors understand the business and reach deeper sections. An individual service page explains one offering in enough detail to support evaluation. Redesigning both pages into short, visually similar summaries can weaken their separate purposes.
Preserve Useful Content Without Freezing Weak Content
Content does not need to remain word-for-word identical. It does need to retain the information that made the page useful.
Before shortening, combining or rewriting a page, identify:
- Questions the existing page answers
- Search queries associated with the page
- Information users need before taking action
- Sections receiving internal or external links
- Verified claims and evidence
- Important definitions
- Images, tables or downloads that add meaning
- Information required for legal or operational accuracy
Avoid removing useful text solely because a design uses less visible space. Tabs and accordions can help organize information, but essential content should remain available in the rendered page rather than being omitted from the mobile version.
Every substantially rewritten or newly created page should begin with a clear website content brief covering its audience, purpose, scope, evidence, internal links and approval requirements.
Rebuild the Information Architecture Carefully
Information architecture determines how pages relate to one another. Navigation is one visible part of it, but the work also includes hierarchy, internal linking and the routes users take between related information.
Review:
- Primary navigation
- Service and product hierarchy
- Categories and tags
- Breadcrumbs
- Footer links
- Contextual links
- Pagination
- Search and filter URLs
- Click depth
- Orphan pages
- Related-content modules
- Mobile navigation
A cleaner navigation menu should not make important pages harder to discover. If a page is worth indexing and using, at least one relevant crawlable page should link to it.
Internal links on the redesigned site should point directly to the final production URLs. Linking to old URLs and relying on redirects creates unnecessary requests and makes future maintenance harder.
Anchor text should describe the destination naturally. A redesign is not an opportunity to replace every internal anchor with the same exact keyword.
Protect the Staging Website
A staging website allows the team to review the redesign before it becomes public, but it can create duplicate URLs or expose unfinished information if it is not controlled.
Password protection or another form of authentication is generally stronger than relying only on search directives. If a staging page is publicly accessible, document any temporary noindex directives and make their removal part of the launch checklist.
Do not assume that blocking a URL through robots.txt will remove or prevent every form of indexing. Google must be able to crawl a page to detect a noindex directive placed on that page. Google explains this distinction in its guidance on blocking search indexing.
Before launch, check the staging website for:
- Temporary or unintended noindex and nofollow directives
- Canonicals pointing to the staging domain
- Internal links pointing to the staging domain
- Placeholder titles and meta descriptions
- Test analytics IDs
- Dummy email addresses and phone numbers
- Placeholder images
- Incomplete forms
- Development scripts
- Unapproved claims
The staging environment should not be treated as safe merely because its URL is difficult to guess.
Create an Old-to-New URL Map
When URLs change, create a mapping before redirects are implemented.
Each row should identify:
- Old URL
- Final destination
- Reason for the change
- Redirect type
- Content owner
- Implementation status
- Test result
Match URLs by user purpose and content relevance. A page about one service should not redirect to a general services page when a closely corresponding service page exists.
Include:
- Pages
- Posts
- Category pages being retained
- Important images
- Downloadable documents
- Campaign landing pages
- URLs with backlinks
- URLs receiving traffic
- Common URL variations
- URLs previously redirected
A mapping is also useful when a URL remains unchanged because it confirms that the team reviewed the page deliberately.
Google’s site-move documentation recommends preparing a URL map, updating internal links, using permanent server-side redirects and monitoring both old and new URLs.
Implement Redirects Without Chains or Loops
Use permanent server-side redirects, such as 301 or 308, when a page has permanently moved.
Redirects should:
- Send the old URL directly to the final destination
- Match the old page with a relevant replacement
- Work for users and search-engine crawlers
- Preserve query parameters only when they remain meaningful
- Avoid unnecessary hops
- Avoid loops
- Resolve consistently across HTTP, HTTPS, www and non-www versions
- Remain active long enough for users and search engines to process the change
A redirect chain such as Old URL → Temporary URL → Final URL adds delay and creates another point of failure. Update the original redirect to point directly to the final destination.
Do not redirect large groups of unrelated URLs to the homepage. Google notes that irrelevant redirects may be treated as soft 404s.
Permanent redirects can transfer search signals, but they do not guarantee that rankings will remain identical. Content changes, altered internal links and a different site structure can affect how the destination is evaluated.
Do Not Use Canonicals as Redirect Replacements
A canonical tag identifies a preferred URL among duplicate or substantially similar pages. It does not send users to a new location and should not replace a redirect when content has permanently moved.
On the redesigned site, verify that:
- Canonical signals point to the intended production URL
- Where rel=”canonical” is used, it references the correct production URL
- Canonicals do not point to staging
- Canonical targets return a successful status
- Canonical targets are indexable
- Internal links and sitemap entries agree with the preferred URLs
- Mobile and desktop implementations use consistent signals
Conflicting signals make the intended destination harder to interpret. For example, the sitemap should not contain one URL while its canonical points somewhere else.
Review Hreflang Where It Is Actually Used
Hreflang is relevant only when a website maintains language or regional alternatives that need to be distinguished.
If the site uses hreflang:
- Preserve all valid language and region codes
- Update annotations when URLs change
- Confirm reciprocal references
- Point each annotation to a working indexable URL
- Use consistent canonical and hreflang logic
- Include an appropriate default version only when the site has one
- Test annotations after launch
Do not add hreflang merely because a company accepts customers from different countries. Separate regional URLs should provide a real reason for users and search engines to distinguish them.
Preserve Metadata and Heading Structure
For each important page, compare the old and redesigned versions.
Review:
- Title element
- Meta description
- H1
- Supporting headings
- Main body content
- Image alternatives
- Canonical
- Robots directives
- Open Graph information where used
- Structured data
- Published and modified information where relevant
Titles and descriptions can be improved during a redesign, but changing all of them at once makes performance changes harder to interpret. Prioritize corrections with a clear reason rather than rewriting every title simply because the design changed.
A page should normally have one clear primary heading. The visual size of a heading and its semantic level are separate decisions; CSS can control appearance without using heading elements purely for styling.
Preserve Structured Data Only When the Page Supports It
Copying structured data from the old website without reviewing the redesigned content can create inaccurate markup.
Confirm that:
- The structured data type fits the page
- Required information is visible or supported by the page
- URLs use the production domain
- Images are accessible
- Organization details are accurate
- Breadcrumb markup matches the visible hierarchy
- Product, service, article or local information is not fabricated
- Removed reviews, ratings, FAQs or offers are also removed from markup
- Mobile and desktop versions remain consistent
Structured data does not compensate for missing or unclear page content.
Test Mobile Content and Rendering
Google uses the mobile version of a page for indexing and ranking. Its mobile-first indexing guidance recommends equivalent primary content, headings, metadata and structured data across mobile and desktop versions.
Test whether the redesigned mobile experience includes:
- The same essential information
- Equivalent headings
- Crawlable navigation
- Descriptive internal links
- Accessible images and alt text
- Working forms
- Usable menus
- Visible calls to action
- Readable tables
- Functional accordions and tabs
- Structured data
- Metadata
- Embedded media
Do not require clicking, swiping or typing before essential content is loaded into the page. Search engines may not interact with a page in the same way as a user.
JavaScript-generated content should be tested in the rendered page. Confirm that essential links use crawlable HTML anchors and that required scripts and styles are not blocked.
Measure Performance by Template
A homepage test does not represent the entire website. Test representative examples of each major template, such as:
- Homepage
- Service page
- Article
- Category or archive
- Contact page
- Landing page
- Product or listing page, where applicable
The current Core Web Vitals focus on loading performance, interactivity and visual stability through LCP, INP and CLS. The official Web Vitals guidance also distinguishes between controlled laboratory tests and real-user field data.
During development, check:
- Server response time
- Image dimensions and compression
- Responsive image delivery
- Font loading
- Render-blocking resources
- JavaScript execution
- Third-party scripts
- Layout shifts
- Lazy loading
- Caching
- CDN behaviour
- Consent and analytics scripts
- Embedded media
Do not remove useful content merely to improve a performance score. Address the underlying delivery problem where practical.
A passing laboratory result is useful but does not guarantee the same experience for real users on different devices and network conditions.
Test Accessibility and Core User Tasks
Accessibility should be considered while templates and components are being designed, not added as a final plugin.
Review:
- Keyboard navigation
- Visible focus states
- Heading hierarchy
- Descriptive link text
- Form labels
- Error identification
- Colour contrast
- Text resizing
- Image alternatives
- Captions or transcripts where appropriate
- Menu operation
- Modal and dialog behaviour
- Touch-target usability
- Table readability
- Skip navigation
- Screen-reader announcements for dynamic changes
The W3C Web Content Accessibility Guidelines overview provides the authoritative framework. Compliance requirements can depend on jurisdiction and context, so a general checklist should not be presented as a legal determination.
Complete real tasks during testing:
- Submit a contact form
- Use website search
- Open navigation on mobile
- Complete a purchase or booking where applicable
- Download a file
- Change consent preferences
- Use account functions
- Recover from a form error
- Reach important service information
A page that renders correctly but prevents users from completing its main task is not ready to launch.
Preserve Analytics and Conversion Measurement
A redesign can appear successful while silently breaking measurement.
Verify:
- Analytics property and tags
- Tag Manager container
- Search Console verification
- Advertising tags
- Consent configuration
- Form-submission events
- Purchase, booking or registration events
- Phone and email interaction tracking
- Thank-you pages
- Cross-domain tracking where legitimately required
- Internal search measurement
- Ecommerce data
- Custom dimensions or business-specific events
Do not record a conversion merely because a button was clicked if the intended task was not completed. The measurement should reflect the actual event the business wants to understand.
Take a record of current identifiers and event names before development. After launch, confirm that events fire once and carry the expected information.
Check Integrations and Operational Requirements
SEO is not the only launch dependency. A redesigned site may rely on:
- CRM forms
- Email platforms
- Payment systems
- Booking systems
- Customer accounts
- Maps
- Consent tools
- Live chat
- Search
- Product feeds
- Advertising platforms
- Webhooks
- APIs
- Security services
Record which integrations are essential, who owns them and how they will be tested. Remove test credentials, dummy destinations and development endpoints before launch.
Confirm that error messages do not expose sensitive technical information and that forms request only the information genuinely needed.
Complete a Pre-Launch Crawl
Crawl the staging or pre-production website when access arrangements permit it, then compare the results with the current site and URL inventory.
Look for:
- Missing pages
- Unexpected new URLs
- Broken internal links
- Redirect chains
- Redirect loops
- Incorrect status codes
- Accidental noindex
- Robots blocks
- Staging canonicals
- Duplicate or missing titles
- Missing descriptions
- Missing or repeated H1s
- Broken images
- Missing image alternatives
- Inaccessible scripts or styles
- Invalid structured data
- Staging-domain references
- HTTP resources on HTTPS pages
- Empty templates
- Placeholder content
- URLs excluded from navigation
- Orphan pages
- Canonical and sitemap conflicts
Test more than the homepage. Select representative pages from every template and high-value section.
Prepare the XML Sitemap
The redesigned sitemap should contain the canonical URLs the site wants search engines to discover.
Before launch:
- Remove staging URLs
- Remove redirected URLs
- Remove error pages
- Remove non-canonical duplicates
- Include important indexable pages
- Use the final protocol and hostname
- Split very large sitemaps where necessary
- Ensure sitemap indexes reference working files
- Update lastmod only when it accurately reflects a meaningful change
The sitemap supports discovery, but it does not replace internal links, correct status codes or useful content.
Prepare the Launch and Rollback Plan
Document the exact launch sequence.
Include:
- Launch date and expected window
- Responsible people
- Current-site backup
- Database backup
- DNS responsibility
- Hosting and CDN responsibility
- Redirect deployment
- Cache clearing
- Robots and noindex review
- Sitemap publication
- Analytics verification
- Form testing
- Security-certificate checks
- Rollback criteria
- Communication procedure
- Post-launch monitoring owner
Where practical, choose a period when the responsible team can monitor the site and respond to problems. Avoid launching immediately before a period when developers, content owners or decision-makers will be unavailable.
Launch-Day SEO Checklist
Immediately after deployment, confirm:
- The production website is accessible.
- HTTPS works correctly.
- The preferred hostname resolves consistently.
- Important pages return successful status codes.
- Removed pages return the intended response.
- Permanent redirects work.
- Redirects point directly to final destinations.
- Pages intended to appear in search are not accidentally marked noindex.
- Robots.txt does not block essential pages or resources.
- Canonicals use production URLs.
- Internal links use final URLs.
- Navigation works on desktop and mobile.
- XML sitemaps contain current canonical URLs.
- Structured data uses production information.
- Hreflang is correct where applicable.
- Forms and other critical actions work.
- Analytics and conversion events are recording.
- Images, scripts, styles and downloads load.
- No visible staging references remain.
- Contact and legal information is accurate.
- A rollback remains available if a critical failure is found.
For a domain or subdomain migration, verify both the old and new properties in Search Console and use Google’s Change of Address tool where applicable. The tool is not required for ordinary path changes on the same domain.
Monitor the Website After Launch
Launching the redesign completes the deployment, not the migration.
During the first checks
Review:
- Priority page availability
- Redirect behaviour
- Forms and transactions
- Analytics events
- Robots directives
- Canonicals
- Sitemap access
- Server errors
- Broken links
- Mobile rendering
- Staging references
During subsequent crawls
Monitor:
- Search Console indexing reports
- Submitted and indexed sitemap URLs
- New 404 and soft-404 reports
- Redirect errors
- Google-selected canonicals
- Organic landing pages
- Important queries
- Conversion activity
- External links still pointing to old URLs
- Core Web Vitals
- Server logs where available
Small fluctuations can occur while search engines recrawl and process changed URLs. Do not respond to every daily movement by making additional large changes. Investigate persistent patterns against the pre-launch baseline.
Keep Redirects Active
Google recommends retaining site-move redirects for at least one year. Keeping useful redirects longer may continue to help visitors who use old bookmarks, external links or saved documents.
Do not remove a redirect simply because the new URL has appeared in search results. Other search engines, users and external websites may continue requesting the old address.
Update important internal links and controllable external destinations to use the final URL. Redirects should act as a migration safeguard rather than the website’s permanent internal-linking system.
Diagnose a Post-Launch Decline Systematically
If important performance falls after launch, separate technical, content and measurement problems.
Check:
- Whether analytics is recording correctly.
- Whether the affected URLs still exist.
- Whether redirects reach the appropriate pages.
- Whether pages remain indexable.
- Whether canonicals changed.
- Whether content was removed or substantially altered.
- Whether internal links were lost.
- Whether navigation depth increased.
- Whether mobile content differs.
- Whether rendering or server errors appeared.
- Whether the sitemap contains the correct URLs.
- Whether the decline affects the whole site, one template or a specific group of pages.
Do not assume every reported traffic drop is caused by rankings. Broken analytics, changed consent behaviour, seasonal demand, campaign changes and conversion failures can produce different symptoms.
Hypothetical Example: Redesigning a Service Website
The following example illustrates the decision process. It is not a real Glorvix client or reported case study.
A service business plans to replace its CMS and simplify its navigation. The current website contains:
- One homepage
- Eight service pages
- Fifteen articles
- Six near-duplicate location pages
- A contact page
- Several downloadable guides
The team first inventories every URL and identifies which pages receive organic visits, external links and enquiries.
The redesign decisions are:
- Retain the homepage URL.
- Retain six service-page URLs.
- Merge two overlapping service pages into one stronger page.
- Preserve twelve articles.
- Consolidate three outdated articles into one current guide.
- Retain two location pages with distinct useful information.
- Remove four unsupported location pages.
- Preserve downloadable guides with traffic and external links.
The team maps each retired URL to a relevant consolidated destination. Pages without a genuine replacement return an appropriate error response rather than redirecting to the homepage.
Before launch, the staging site remains access-controlled. The team tests redirects, canonicals, navigation, mobile content, forms and tracking. After launch, it compares the new crawl and performance data with the saved baseline.
The example shows why the redesign process begins with evidence and page purpose rather than the new visual layout.
Common Website Redesign SEO Mistakes
Changing URLs without a reason
A shorter URL is not automatically better than a stable descriptive URL. Every unnecessary change creates migration work and another opportunity for error.
Designing before completing the content inventory
Templates created without understanding existing content may not support essential tables, comparisons, evidence, downloads or page types.
Removing useful information for a cleaner appearance
Visual simplicity should improve comprehension, not remove the details customers need.
Redirecting all removed pages to the homepage
An irrelevant redirect does not provide a useful replacement and may be treated as a soft 404.
Using canonical tags instead of redirects
Canonicals and redirects serve different purposes. A permanent move should normally use a permanent redirect.
Leaving staging controls on production
An accidental noindex, authentication requirement or restrictive robots rule can prevent important pages from being processed.
Copying staging canonicals into production
Every indexable page should reference the intended production canonical.
Forgetting internal links
Redirects do not remove the need to update navigation and contextual links to their final destinations.
Testing only the homepage
Problems frequently affect one template, integration or content type rather than the whole site.
Ignoring mobile content
A visually compressed mobile layout must still provide the essential content and signals available on desktop.
Treating performance scores as the whole redesign
Speed matters, but a fast page can still have unclear content, inaccessible controls or broken conversion paths.
Launching without a measurement baseline
Without a baseline, the team cannot reliably distinguish an old issue from a redesign problem.
Making several major changes without a diagnostic plan
Simultaneously changing the domain, CMS, structure, content and tracking makes it harder to identify the source of a problem.
Master Website Redesign SEO Checklist
Planning
- Define the redesign type.
- Record what will and will not change.
- Assign owners and reviewers.
- Create backups.
- Document rollback conditions.
- Record search, content, technical and conversion baselines.
Content and URL decisions
- Build a complete URL and asset inventory.
- Identify important organic and business pages.
- Assign every URL a decision.
- Preserve essential page information.
- Prepare briefs for new or rewritten pages.
- Approve consolidations and removals.
- Create an old-to-new URL map.
Design and development
- Preserve page purpose.
- Build crawlable navigation.
- Maintain useful internal links.
- Protect staging.
- Implement final canonicals.
- Review structured data.
- Review hreflang where applicable.
- Test rendered content.
- Maintain mobile content parity.
- Test performance by template.
- Test accessibility.
- Test forms and integrations.
- Configure analytics and conversion events.
Pre-launch
- Crawl the staging website.
- Compare it with the current URL inventory.
- Test all planned redirects.
- Remove placeholder content.
- Remove staging references.
- Confirm production robots directives.
- Validate metadata.
- Validate structured data.
- Prepare the production XML sitemap.
- Confirm Search Console verification.
- Approve the launch and rollback plan.
Launch
- Deploy the approved website.
- Activate redirects.
- Test priority URLs.
- Confirm indexability.
- Check canonicals.
- Check robots.txt.
- Publish the sitemap.
- Verify forms and conversion actions.
- Verify analytics.
- Check HTTPS and preferred hostname.
- Crawl the production website.
Post-launch
- Monitor server and crawl errors.
- Review indexing reports.
- Check sitemap processing.
- Monitor organic landing pages.
- Monitor conversions.
- Investigate persistent declines by template and URL group.
- Update internal and controllable external links.
- Keep permanent redirects active.
- Record fixes and significant post-launch changes.
Frequently Asked Questions
Can a website redesign affect SEO?
Yes. A redesign can affect search performance when it changes URLs, content, navigation, internal links, technical directives, rendering or page speed. A visual redesign with stable URLs and carefully preserved information generally involves fewer migration risks than a project that changes several systems simultaneously.
Do unchanged URLs need redirects?
No. A redirect is not needed when the URL remains exactly the same and continues serving the intended page. The page should still be checked for changes to its content, canonical, metadata, internal links and indexability.
Should every title and meta description remain unchanged?
Not necessarily. Keep effective metadata when the page’s purpose remains the same. Update inaccurate, duplicated or unclear metadata where there is a documented reason. Avoid changing every title automatically merely because the design changed.
When is Google’s Change of Address tool needed?
It is intended for moves from one domain or subdomain to another. It is not required for ordinary URL-path changes within the same domain or for switching from HTTP to HTTPS.
How long should redirects remain active?
Google recommends keeping site-move redirects for at least one year. Useful redirects can remain longer to support old external links, bookmarks and other search engines.
Can a redesign guarantee improved rankings?
No. A redesign can correct technical problems and improve usability, content structure or performance, but rankings cannot be guaranteed. The outcome also depends on content relevance, competition, search demand, external signals and how search systems evaluate the updated pages.
What should be checked immediately after launch?
Start with production availability, status codes, robots directives, canonicals, redirects, internal links, mobile rendering, forms, analytics and the XML sitemap. These checks identify problems that can affect both discovery and essential user actions.
Protect the Website Before Replacing Its Design
A successful redesign preserves more than appearance. It protects useful content, stable destinations, internal relationships, measurement and the routes customers use to complete important tasks.
Begin with a reliable inventory and baseline. Decide what each page should become, map every necessary URL change and test the redesigned site before it replaces the existing version. After launch, monitor evidence rather than assumptions and correct persistent problems without introducing another uncontrolled set of changes.
The objective is not to keep every element of the old website. It is to make sure that useful information and established access paths are not lost merely because the presentation has changed.