How to Protect SEO During a Website Redesign

To protect SEO during a website redesign, keep useful URLs and content where possible, map every necessary URL change, test permanent redirects, and check the live site before signing off. For manufacturers, that includes product pages, specifications, CAD downloads, manuals, and the routes buyers use to request a quote.

A cleaner design can still remove the information that brought an engineer or purchasing manager to your website. A product page may look better while losing its model number, application details, or installation guide. An old distributor link may lead to a missing PDF. These are migration decisions that need attention before launch.

This website redesign SEO checklist gives marketing teams and developers a shared process for protecting search visibility and useful buyer journeys. It reduces avoidable errors; it cannot guarantee unchanged rankings.

First, decide whether URLs need to change

A visual redesign can keep the same domain, page addresses, and content. A website migration may change the CMS, hosting, domain, or URL structure. Even a CMS change can preserve existing URLs if the development team plans for them.

Keep a working product or capability URL unless there is a clear reason to change it. A new design does not require a new slug. Where practical, separate a domain move from a CMS replacement and major content changes so problems are easier to isolate.

The checklist below applies to both situations. If URLs stay the same, concentrate on content, navigation, rendering, indexing settings, and measurement. If URLs change, add a complete migration map and redirect testing.

1. Record what the existing site contributes

Before development changes the live site, save a dated performance baseline. Use enough history to identify seasonal patterns, alongside the most recent comparable period.

• Search Console: Export pages, clicks, impressions, queries, and average position. Review the countries you serve, including the US where relevant, and separate branded from nonbranded searches. Inspect important pages individually.
• GA4: Record organic search landing sessions and verified inquiry events. Keep referral and identifiable AI assistant referrals separate from organic search. Compare like dates and channel definitions after launch.
• Sales context: Identify pages supporting qualified RFQs, distributor inquiries, or active opportunities. A low-traffic capability page can matter more than a popular general article.

Record the launch date and later fixes in a change log. Check that form completion events represent successful submissions. A download or a click on “Request a quote” is not automatically a qualified lead.

Keep this baseline by page group: products, capabilities, applications, technical resources, and articles. Sitewide totals can hide a loss affecting one commercially important section.

2. Inventory pages, files, and their dependencies

Build an inventory from a site crawl, XML sitemaps, CMS exports, Search Console, analytics, and available backlink or server log data. A crawl alone can miss a document linked only from a distributor website or an old catalog.

For each URL, record its page type, status, title, canonical, indexing rules, internal links, and relevant search or business value. Include PDFs, drawings, images, and any separate file host used for public resources.

For an industrial website, specifically check:

• Product families and individual model or part pages.
• Capability and application pages that answer supplier selection questions.
• Datasheets, installation instructions, certifications, and CAD files.
• Legacy product support pages and revision-specific manuals.
• Filtered catalog URLs, pagination, and links from product configurators.

Assign an owner to each group. Marketing can judge search intent, engineering or product teams can confirm technical accuracy, and development can verify how the content is delivered.

3. Build the old URL to new URL map

Create the map before URLs are removed. Give each existing URL an explicit decision: keep, move, consolidate, or retire. Record the exact destination, expected response code, reason, owner, and test result. Store full URLs in the working sheet, including the hostname when files use a separate domain.

The shortened paths below are illustrative. They do not describe a c3digitus client migration.

Consolidate pages only when the destination genuinely answers their original purpose. A general “Capabilities” page may not replace a detailed precision machining page. Review useful copy, backlinks, search queries, and customer needs before removing the detail.

Do not redirect every deleted URL to the homepage. Google can treat irrelevant redirects as soft 404s. If no suitable replacement exists, a genuine error response is more accurate. See Google’s guidance on HTTP status codes.

4. Implement and test permanent redirects

For pages that permanently move, use a server side 301 or 308 redirect to the approved destination. Both are supported by Google. A temporary 302 should not be the default for a permanent migration. See Google’s redirect guidance.

Test the complete mapping automatically where possible, then manually inspect important destinations. A technically successful redirect can still lead to the wrong product.

• Each moved URL reaches the correct final destination directly, without a loop or unnecessary chain.
• The destination returns 200, contains the intended content, and is indexable when it should appear in search.
• Existing redirects still work after the CMS or server configuration changes.
• HTTP, HTTPS, hostname, trailing slash, and parameter variations resolve consistently where applicable.
• PDF and download redirects are tested separately from HTML pages.

Update internal links to final destinations instead of relying on redirects throughout the new website. Keep migration redirects for at least one year, as Google’s site move guidance recommends. Keep useful ones longer when catalogs, bookmarks, or distributor links still depend on them.

5. Preserve the content buyers came to find

Compare the old and proposed version of every priority page. Preserve its useful purpose and technical substance, while correcting obsolete or inaccurate information.

On a product page, that may mean keeping model names, operating ranges, dimensions, material options, compatibility notes, and document links. On a capability page, it may mean materials, process limits, inspection methods, and information needed for an RFQ.

For example, replacing a sensor page’s pressure range and output options with a large photograph and “Built for demanding applications” makes evaluation harder. Move the specifications into a clearer table, but keep them accessible as text. Check that the mobile version retains the important information too. Google’s mobile indexing guidance explains why content parity matters.

Retain effective titles and headings where they still describe the page accurately. Rewrite them when the intent or offering changes, rather than resetting every page to a generic template. Review existing structured data against the new visible content.

Use our on page SEO guide for B2B companies and manufacturers for the wider content review.

6. Protect technical documents and product discovery

A PDF migration needs more than a working download button. Open the file and confirm the model, revision, language, and document type. An installation manual for a discontinued machine is not interchangeable with the newest model’s manual.

Keep useful legacy documentation accessible, with clear product status and applicability. If a public datasheet changes location, update its links from product pages and relevant resource listings. Check whether document delivery adds an unintended X-Robots-Tag: noindex header. Google uses that header for indexing controls on non-HTML files such as PDFs.

Review navigation alongside the documents. Can someone move from a product family to a model, compare its specifications, download the correct file, and start an RFQ? Important pages should have relevant, crawlable links. Do not make internal search or a JavaScript action the only route to them. Google’s link guidance describes the supported HTML link format.

For large catalogs, agree which filter combinations should be discoverable and indexable. Do not accidentally remove valuable category pages or create unlimited indexable combinations during the rebuild.

7. Check staging before scheduling launch

Use a protected staging environment for development. Password protection controls access; noindex is an indexing instruction, not a security measure. Google must be able to crawl a URL to see its noindex instruction, so robots.txt blocking is not a substitute for it.

Test every page template and the priority URLs. Confirm content, document links, mobile layouts, forms, and required scripts work. Check that important content is present in the rendered page, not just in the CMS editor. Compare loading, responsiveness, and layout stability with the old templates, especially on product pages with large images or configurators.

Prepare separate production settings. Public pages intended for search must not inherit staging noindex rules, access restrictions, or canonicals pointing to the staging domain. Keep staging protected after production launches. Google’s robots meta and HTTP header guidance covers these indexing controls.

Agree who can approve launch and who can pause it. Take backups and document a rollback process that protects new inquiries or orders received after launch. Do not schedule the release when the people needed to fix it are unavailable.

8. Run the launch checks on production

Staging approval does not confirm production behavior. Test the live website immediately after deployment, including the old URLs. Use the checks below as release criteria.

For unique indexable pages, check that the canonical identifies the intended production URL. For duplicates, confirm the chosen primary URL. A canonical is a signal, not a replacement for redirecting a moved page. Google’s canonical guidance explains the distinction.

Follow Google’s sitemap guidance when submitting the updated file. Submission helps discovery; it does not guarantee indexing. Preserve Search Console verification and test analytics, consent settings, file downloads, and the complete quote submission route.

For a domain move, verify the relevant properties and follow Google’s Change of Address process where applicable. It is not needed for a redesign that only changes paths on the same domain. If the site uses hreflang for regional or language versions, update those references to the correct new URLs too.

Pause signoff for critical failures: broad indexing blocks, incorrect canonical templates, broken priority redirects, missing product information, or failed inquiry delivery. A working homepage does not establish that the migration is ready.

9. Monitor by page group and investigate drops

During the first week, check daily for unexpected errors, failed redirects, missing content, and inquiry problems. Review search trends weekly once enough data is available, and continue until priority sections have stabilized. This is an operating schedule, not a promised recovery timeline.

Compare Search Console clicks and impressions for the affected pages and queries, using consistent country and device filters. In GA4, compare organic landing sessions and valid inquiries. Report referral and identifiable AI assistant traffic separately, without counting the same sessions twice. Use sales follow-up to judge inquiry quality.

If performance falls, investigate in this order:

1. Access and indexing: Inspect affected URLs for errors, crawl blocks, noindex, or an unexpected canonical. Search Console’s indexed result and live test answer different questions.
2. Migration implementation: Recheck redirects, missing files, internal links, and template changes against the map and baseline.
3. Content and demand: Compare lost queries with removed information, changed intent, seasonality, and wider ranking changes.
4. Measurement: If Search Console is stable but GA4 falls sharply, inspect tracking and consent changes before declaring an SEO loss.

Google’s URL Inspection documentation and traffic drop diagnostic guide support this investigation. Do not assume every decline is normal migration volatility or wait for rankings to recover while a known defect remains live.