A new website is exciting. Fresh design, faster pages, a better way to manage content. But many businesses discover, a few weeks after launch, that the phone has gone quiet and the enquiries from Google have thinned out. The new site looks great; the old one was simply being found.

Search engines do not see your redesign. They see that URLs they knew have changed or vanished, that page content is different, and that signals pointing at the old pages now lead nowhere. A migration done carelessly throws away years of accumulated trust. Done carefully, it is a routine project.

This checklist is written for business owners and managers who need to know what should happen, what to ask for, and what to verify. Whether you move to a new design, a new platform or a new domain, the same principles apply.

Step 1: Record what you have today

You cannot tell whether a migration hurt you without a baseline. Do this before any work begins, because it is much harder to reconstruct afterwards.

  • List every URL on the current site. Export it from your CMS or run a crawl, and keep it in a spreadsheet. This becomes the backbone of the whole project.
  • Export search performance. From Google Search Console, save which pages and which search queries bring clicks and impressions.
  • Note which pages bring business, not just visits. In your analytics, mark the pages that lead to enquiries, bookings, WhatsApp clicks or sales.
  • Identify pages with outside links. Pages that other websites link to carry value you do not want to lose. Search Console's links report is a starting point.
  • Save the key on-page elements. For important pages, record the page title, meta description and main headings.
  • Back up everything. Keep a full copy of the old site and its database somewhere safe, and keep it available for a while after launch.
  • Document your tracking. Write down analytics tags, ad pixels, conversion events and any site verification codes, so none of them silently disappear.

Step 2: Decide what changes and what stays

Not every page deserves to survive, and not every URL has to change. Make these decisions deliberately and write them down.

Keep URLs wherever it is reasonable

The simplest way to avoid redirect problems is to avoid changing the address in the first place. If a page at /layanan/desain-web/ performs well and still fits, there is often no strong reason to rename it. Platform changes sometimes force new URL patterns, but ask your developer whether the old structure can be reproduced before accepting a new one.

Map every old URL to a new destination

For each old URL that will change or disappear, decide where a visitor and a search engine should land instead. This is your redirect map, and it should be a spreadsheet with two columns: old address, new address. Some principles:

  • Use permanent (301) redirects, which tell search engines the move is lasting.
  • Send each old page to the most relevant new page, not to the homepage. Redirecting everything to the homepage looks lazy to search engines and frustrates visitors.
  • Avoid chains, where A redirects to B, which redirects to C. Point A straight to C.
  • Include old image, PDF and category addresses if they had traffic or links.

Tip: Sort your redirect map by organic traffic and links, then personally test the top of the list after launch by clicking each old address. If your most valuable pages land in the right place, most of the risk is covered.

Decide what to retire

Old news posts, duplicate pages and outdated offers may not belong on the new site. If a similar page exists, redirect to it. If there is genuinely no equivalent, it is acceptable for the old address to return a clean "not found" page, as long as you chose that on purpose and the page was not an important one.

Step 3: Carry over the signals that matter

Pages that rank do so because of their content and structure. A redesign that rewrites everything also rewrites the reasons those pages were found. For every important page, check that the new version keeps:

  • The same main topic, with copy that is at least as complete as before.
  • A clear page title and meta description, written for people and not stripped to defaults.
  • Logical headings, with one main heading and sensible sub-headings.
  • Internal links to related pages, including links within body text, not only menus.
  • Image descriptions (alt text) and sensible file names.
  • Structured data, if the old site had it, such as business details or reviews.
  • Canonical tags that point to the correct address of each page.
  • Language versions, if you serve both Indonesian and English, linked to each other correctly.

If you plan to improve content, that is welcome, but improve it rather than shrink it. A page that gets thinner is a page that can slip.

Step 4: Build and test on a staging site

A staging site is a private copy of the new website where mistakes are cheap. Insist on one.

  • Block it from search engines. A staging site that gets indexed creates duplicate content and confusion. Equally important, check that the block is removed at launch. A forgotten "noindex" setting is one of the most common and most damaging migration mistakes.
  • Test the redirect map against the staging or launch configuration before going live.
  • Crawl the staging site and compare it with your original URL list. Look for missing pages, broken links and error pages.
  • Check mobile display on real phones, since most Indonesian visitors arrive on them.
  • Test every form, button and integration: contact forms, WhatsApp links, payment steps, booking flows and email notifications.
  • Check speed on key pages. New designs sometimes add heavy images or scripts that make the site slower than the old one.
  • Confirm tracking works, so conversions are still recorded from day one.

Step 5: Launch-day checklist

  1. Take a final backup of the old site.
  2. Switch the site live and activate the redirects.
  3. Remove any search-engine block left over from staging.
  4. Confirm the secure (HTTPS) version loads without warnings, and that the non-secure and "www" variants redirect to your preferred address.
  5. Check the robots.txt file is not blocking important sections.
  6. Submit the new XML sitemap in Google Search Console.
  7. If the domain name changed, use Search Console's change-of-address tool and keep the old domain's redirects active.
  8. Click through the top old URLs and confirm each redirects to the right new page.
  9. Submit a test enquiry and a test purchase or booking, if relevant.

Where possible, avoid launching right before a busy trading period or a holiday, when nobody is around to fix problems quickly.

Step 6: Watch closely after launch

A migration is not finished at go-live. Search engines need time to revisit and reprocess your pages, and small errors only show up once real traffic arrives.

  • Review the Search Console coverage and indexing reports for new errors, especially "not found" pages that used to exist.
  • Compare clicks and impressions against the baseline you saved in step 1, looking at your top pages individually, not only totals.
  • Re-crawl the live site to catch broken links and redirect chains.
  • Watch enquiries and conversions, not just traffic. A traffic dip with steady enquiries means something different from the reverse.
  • Fix issues quickly and keep a log of what you changed.
  • Keep the redirects in place for as long as old URLs still have links or visitors. They cost almost nothing to maintain.

Some movement in rankings right after a migration is normal while search engines catch up. A sustained decline in specific pages is a signal to investigate the redirect, content or technical settings for those pages.

Takeaways to keep

  • Record your URLs, search performance and tracking before anything changes.
  • Keep URLs the same where you reasonably can, and map every one that has to change.
  • Redirect to the most relevant page, never blanket-redirect to the homepage.
  • Do not shrink or strip the content of pages that currently perform.
  • Use a staging site, and double-check that search-engine blocks come off at launch.
  • Monitor by page and by enquiry for weeks after launch, not just on launch day.

When comparing agencies, ask each one to explain how they handle URL mapping, redirects and post-launch checks. A proposal that does not mention them is worth questioning, and our guide on how to compare web development proposals covers other items to look for.

Frequently asked questions

Will my rankings drop after a migration?

Some fluctuation is common while search engines reprocess the new site, and no one can honestly guarantee otherwise. The risk is reduced when URLs are kept or redirected correctly, content stays at least as strong, and the technical settings are checked at launch. Lasting drops usually trace back to a specific, fixable mistake.

Should I redesign and migrate at the same time?

It is possible, but each extra change makes it harder to identify the cause if traffic falls. If search traffic is important to your business, consider keeping URLs and core content stable during the move, then refining content and structure in later rounds. If a full rebuild is the better choice, careful tracking and a solid redirect map matter even more.

Can I do a migration myself, or do I need a developer?

A small site on a familiar platform can sometimes be handled in-house with careful planning. Anything involving a platform change, a new domain, many pages or online sales is safer with a team that has done it before. Our website and WordPress development work includes planning for this kind of move.

If you are planning a website move and want a second opinion on the risks, you are welcome to get in touch with the Digital Revo team.