When many business owners redesign their corporate website, their biggest worry isn't whether the design looks good—it's that after the new site goes live, keywords that used to rank can no longer be found, and traffic drops as if unplugged.
Most of this can be prevented during the website development phase. When indexing does drop, it's usually because a few small things were missed during migration, not because the new site itself has problems.
Below, I'll explain in the order of an actual project, in plain language.
1. Define URL Rules Before Touching Code
The most error-prone part of migration is URLs. The old site uses `/product/123.html`, while the new site becomes `/product?id=123`, or the category names are completely changed—search engines will treat these as a batch of new pages and re-evaluate them from scratch.
The approach is simple: before migration, pull together a list of old URLs from the CMS, sitemap, and search console, and mark each one as either "keep the original path" or "redirect to a new path." Keep as many as possible, especially category pages and article pages that already have rankings.
Pitfall: don't rewrite all URLs just to "look tidy." Tidiness is for people; indexing is for crawlers. When the two conflict, prioritize indexing.
2. Do 301 Redirects Thoroughly—Not Just for the Homepage
301 redirects are the lifeline of migration. A common mistake is redirecting only the homepage while all inner pages return 404.
The correct approach is one-to-one mapping: old page A redirects to new page A, not everything to the homepage. Redirecting everything to the homepage is essentially telling search engines "this content is gone," and indexing will drop quickly.
Another detail: redirect chains should not exceed one hop. A redirects to B, and B redirects to C—crawlers can easily break. During website development, have the technical team configure A directly to C.
If it's a corporate website redesign with major category structure changes, it's advisable to crawl the old site with a crawler tool before launch, generate a redirect rules table, and hand it to developers to implement—rather than patching things up after launch.
3. Don't Rewrite the Entire Site's Content—Do Mapping First
Some teams rewrite all copy during a redesign—titles, descriptions, and body text. As a result, new pages and old pages "don't match up," search engines need to re-judge relevance, and rankings fluctuate noticeably.
A more stable approach: keep the original themes and keywords for core pages, migrate the structure first, and gradually optimize copy after launch stabilizes.
A concrete example: a company in industrial equipment redesigned its website, and the old site had over 80 product pages. During migration, they moved product specs, model numbers, and application scenarios over as-is, only adjusting layout and navigation, and kept the original model keywords in titles. Two weeks after launch, indexing for the main product pages was largely retained. Conversely, if they had replaced model keywords with brand slogans at the time, they would likely have had to rebuild rankings from scratch.
4. Launch Pacing: Validate with Low Traffic First, Then Switch Fully
Migration should not be an all-or-nothing cutover.
A viable pace: first run the new site on an internal network or test domain, checking that redirects, sitemaps, robots, and canonical tags work properly; then switch during an off-peak period, immediately submit the new sitemap after switching, and monitor crawling and indexing changes in the search console.
There are three pitfalls:
- Don't accidentally block with robots.txt: test environments often have `Disallow: /`, and if it's not removed at launch, the entire site can't be crawled.
- Don't let canonical point to the old domain: this is easily carried over when copying templates.
- Don't put only the homepage in the sitemap: it should include main categories and content pages.
5. Mini Programs and Apps Are Not Substitutes—Don't Mix Them Into Migration
Some companies want to use a redesign to funnel traffic toward mini program development or App development. That's fine, but don't take website content offline directly. Websites, mini programs, and Apps each have their own entry points, and search engines only recognize the website version.
If you do need mini program development, it's advisable to keep complete content pages on the website, use the mini program for interactive features like bookings, memberships, and orders, and share the same content source across both. This way, neither indexing nor business is affected.
When It Makes Sense to Work With MIC Studio
If you're facing any of these situations, consider bringing in an external team:
- The old site structure is messy, no one can clearly say which pages have traffic, and it needs to be sorted out before migration;
- There are no dedicated front-end and back-end staff internally, and the website development timeline is tight;
- Indexing has already declined after migration, and redirect and indexing issues need to be diagnosed;
- You need corporate website, mini program development, or App development at the same time, and want content and technical standards to be unified.
When MIC Studio handles corporate website development and migration, we're used to producing the old URL list and redirect table first, then discussing design and features. Get the order right, and there's less rework later.
Three Actionable Recommendations
1. Export the old URL list before launch, confirm keep-or-redirect for each one, and hand a table to developers.
2. Do one-to-one 301 mapping, keep redirects to no more than one hop, and submit the new sitemap immediately after launch.
3. Preserve content on core pages before changing copy, and do keyword optimization after two weeks of stable operation.
Migration isn't just moving pages over—it's more like moving house: keep the addresses right, make sure someone points the way from old addresses, and don't randomly swap things out. Do these things, and indexing will largely hold.