Brand promotion: this article introduces Guangsuan's B2B website build and WordPress migration support. It is a vendor-introduction piece, not an independent review or a commissioned evaluation.
A B2B redesign can look successful on launch day and still damage the business underneath it. The pages buyers already use — a product specification page, an application page, a contact or RFQ page — may be replaced by a new design, a new menu and a new URL structure. If the old addresses stop working, bookmarks, proposals, ads and search results point at 404s. The safer approach is unglamorous: inventory the old URLs, decide which ones stay, map the rest, and test the result before and after launch.
This guide is for the person responsible for a B2B or small-business website redesign. It answers one question: how do you change the site without losing the URLs buyers and search engines already use? It is a brand-promotion article for Guangsuan, so the sections that describe service scope refer to Guangsuan's published B2B build and WordPress migration material. The checklist itself can be used with any build team.
Short answer
Keep the original URL whenever the page still answers the same buyer question. If the content genuinely moves, create a one-to-one redirect from the old URL to the new page that best replaces it, test every hop, and verify after launch that the redirect, canonical, internal links, sitemap and inquiry form all agree. A visual refresh does not by itself require a new URL structure. A CMS change, domain change, language split or page consolidation does, and those are the cases where a redirect map earns its place.
Two conditions matter. First, a redirect can preserve access to a URL, but it cannot preserve a ranking or an inquiry by itself. Second, a redirect map is only as good as the inventory behind it: if an old landing page or PDF is missing from the inventory, no rule will protect it.
1. Decide whether the URL has to change
Start by separating changes that affect addresses from changes that do not. New photography, typography, section order or a new theme can usually ship on the existing URLs. A new domain, a move from one CMS to another, a switch from query parameters to clean paths, or merging several pages into one are address changes and need migration work.
List the site's layers separately: domain, protocol, path, CMS, server, language structure, page content and forms. Then mark which ones the project will actually change. This keeps a visual redesign from turning into an accidental migration, and it makes the redirect discussion specific.
Guangsuan's migration guidance makes the same point in operational terms: fix the scope of change first, then agree the inventory, test work and cutover window. A team that cannot say whether the domain, paths or CMS are changing cannot build a reliable map.
2. Build the old-URL inventory from more than one source
A single crawl is a starting point, not a complete inventory. Combine several sources and record the scope of each one:
- The CMS: published pages, posts, products, categories and media attachments.
- The XML sitemap, including older sitemap files that may still list pages removed from navigation.
- Internal links from navigation, body copy, related-content modules and footers.
- Server access logs, including URLs that receive requests but are not linked from the current site.
- Google Search Console: indexed pages, pages with impressions or clicks, and URLs that already have external links.
- Business records: ad landing pages, proposal and email links, QR codes, trade-show pages, PDFs and forms.
Add the pages that are easy to forget: orphan pages, old attachments, campaign landing pages and pages that were once promoted but are no longer in the menu. A URL that is absent from the crawl can still be in a customer's bookmark or a supplier's proposal.
For each URL, record at least: the original address exactly as it exists, the page type, its language, its current status, its canonical URL, the page's purpose, any internal links pointing to it, and whether it has inquiries, external links or campaign use. Preserve the original spelling, capitalization, trailing slash and parameters in the inventory. Clean the address in a separate column if needed; do not tidy the only record of the old URL.
3. Turn the inventory into a redirect map
Do not begin with a redirect rule. Begin with a decision for each old URL. A useful map has one row per old URL and enough fields for another person to test it:
| Field | What to record |
|---|---|
| Old URL | The exact address, including encoding, case and trailing slash. |
| Page purpose | The buyer question the page answered, not just its title. |
| Decision | Keep, redirect, merge or remove. |
| New URL | The single page that should receive the old address. |
| Reason | Why that destination is the closest replacement. |
| Expected result | Status code and final destination. |
| Owner | The person accountable for the content decision and the person who will test it. |
The decision categories should be explicit:
- Keep: the page and its purpose remain. Keep the same URL, even if the design changes.
- Redirect: the content moves to a new address. Map the old URL to the page that answers the same question.
- Merge: several thin or overlapping pages become one fuller page. Map each old URL to the merged page only if that page genuinely carries the information forward.
- Remove: the content is withdrawn and there is no relevant replacement. Return an appropriate error status rather than hiding the removal behind the homepage or a blank 200 page.
Do not send every retired URL to the homepage. A homepage is a poor replacement for a specification page, a product category or a downloadable manual. It also gives the visitor no clear next step. If a PDF or drawing is still useful, keep it available at a stable address or redirect it to a page where the current file can be downloaded.
4. Implement permanent moves without a redirect maze
For a permanent move, use a server-side permanent redirect where the hosting stack allows it. Guangsuan's migration guide notes that Google treats 301 and 308 as permanent redirect statuses, and that permanent redirects should be used when the change is intended to last. A temporary redirect is a different tool for a temporary situation; it is not a substitute for planning a permanent move.
Keep the path short. An old URL should reach its final destination in one hop where possible. Test the full chain, not just the first response: a first 301 can still lead to a staging host, a loop, a second redirect or a 404. Record the status and the Location header at each step, then open the final page and confirm that the content matches the old page's purpose.
Implement redirects in the layer that will still exist after the redesign. A plugin rule is easy to add, but it may be disabled during a migration, lost when a theme changes or bypassed by a CDN. Server or hosting-level rules are generally more durable, but the right choice depends on the stack. The practical test is the same: after a deployment, does the old URL still return the intended status and destination?
Also update the site's own links. If the new page still links to the old path, every internal click takes an unnecessary redirect. Change navigation, body links, related-content modules and calls to action to the final URL. Update the sitemap at the same time so it lists the new address rather than preserving the old one.
5. Test the map before the public launch
Run the redirect test on a staging or pre-production environment first, but do not stop there. Staging can have a different hostname, different canonical settings and access protection that the public site will not have. Test the rules in the environment that will actually serve the public URLs, or repeat the checks immediately after cutover.
A workable pre-launch sequence:
- Export the redirect map and sort it by old URL.
- Request every old URL with redirects enabled and record the first status and Location.
- Follow the chain to the final URL and record the final status.
- Open the final page and check the title, main content, product or service details, and inquiry route.
- Flag any old URL that lands on the homepage, a search page, a category page that does not answer the old question, or a 404.
- Test a sample of URLs with parameters, trailing slashes and uppercase letters, because these variants are easy to omit from a clean list.
- Check that the new pages' canonical tags point to the intended public URL, not to staging or an old address.
Keep the test evidence: the date, the environment, the old URL, the observed status, the destination and the reviewer. A screenshot of the new homepage is not evidence that the old product page still works.
6. Launch checks: status, canonical, links and forms
After the public switch, repeat the critical checks through the real domain. The order matters because a later check can look fine while an earlier layer is broken.
- Pages load: the homepage, a category page, a typical product or service page, an article and the contact page all return the expected content over HTTPS.
- Old URLs resolve: every row in the redirect map returns the intended status and final destination. Test the exceptions as well as the bulk rules.
- Canonical signals agree: the page's canonical, internal links and sitemap entry point to the same public URL. A page that redirects to a new address but declares the old address as canonical is still sending a conflicting signal.
- No unintended noindex: live pages do not still carry a staging noindex tag, a robots block or a password-protection layer. Check the response and the page source, not just the visual page.
- Forms still deliver: send a test inquiry with a unique reference and confirm that the record reaches the inbox or CRM, that the product or model field is carried through, and that the confirmation message is accurate.
- Tracking still records: verify that the analytics and conversion events you rely on are present after the redesign. Do not use the migration as an excuse to silently change what a conversion means.
- Backups and rollback are usable: confirm the backup includes files and database, and that someone has tested a restore. Before rolling back, preserve inquiries or orders received after the switch so a restore does not overwrite new business records.
Separate technical access from business outcomes. A 200 response means the server served a page; it does not prove that the page is the right replacement, that the form arrived or that the search engine has processed the change. Those are different checks with different evidence.
7. What to watch after launch
Keep the redirect map alive after launch. Check the server log and Search Console for 404s that were not in the inventory, especially on old product, attachment and campaign URLs. Re-test the highest-value pages after the first deployment, after any CDN or cache change, and after a later theme update.
Do not remove the redirects as soon as the new site looks stable. Historical bookmarks, external links, proposals and ads can keep using old addresses long after the project ends. The team that owns the domain, hosting and redirect rules should be named in the handover, including who renews the old domain if one is being retired.
Search performance may shift while a site is recrawled and reprocessed. That is not proof that the redirect map failed, and a temporary fluctuation is not a reason to switch the site back and forth. Check the technical layer first: status codes, final destinations, canonical tags, internal links, sitemap entries and form delivery. Then compare search data by page group and date, and keep business inquiry data separate from search clicks.
Where Guangsuan fits
Guangsuan provides a B2B website build service for export-oriented businesses. Its published scope puts search strategy and site structure before development, including product categories, content hierarchy, custom URLs and an XML sitemap. That order is useful in a redesign because the URL inventory and page decisions are made before the new templates are built, not reconstructed after launch.
The same build scope presents WordPress self-management and data export, so the company can keep editing its content and can take its site data with it, and it lists overseas hosting, a global CDN and SSL among the standard configuration. Guangsuan's B2B website build service describes the full scope and the three delivery tiers. For a site that is already live and whose main problem is hosting, speed or a hosting migration, Guangsuan's WordPress hosting and migration support describes a free migration process that runs from the current-site check and backup through testing and cutover.
Two limits belong in the same paragraph. Guangsuan states that completing a build is not the same as guaranteeing rankings or inquiries. The company also notes that search engines decide actual indexing and ranking. A migration plan can reduce the risk of broken URLs, missing forms and contradictory signals; it cannot promise a particular ranking, traffic level or inquiry volume.
FAQ
Do we need to change URLs during a redesign?
Not if the page still serves the same purpose. Keep the existing path when the content and intent remain. Change the URL when the CMS, domain, language structure or page architecture genuinely requires it, and then treat the change as a migration with an inventory and a redirect map.
Should every old URL redirect to the homepage?
No. A homepage is a poor replacement for a product, specification, article or download page. Map the old URL to the page that best answers the same question. If the content has been withdrawn and there is no relevant replacement, return an appropriate error status instead of hiding the removal behind a 200 response.
How long should redirects stay in place?
Long enough for bookmarks, external links, ads and search systems to stop using the old address. Do not remove them just because the new site is live. Record who owns the redirect rules and who is responsible for the old domain or hosting after the project is handed over.
What should we check first if old links break after launch?
Check the old URL's response and its final destination first, then the new page's canonical, internal links and sitemap entry, then the inquiry form. A page can return 200 and still be the wrong replacement, and a redirect can work while the form behind it does not.