I do twelve things immediately after a site migration before Google recrawls my site. I lock the permalink structure, build and import a perfect redirect map, test every redirect until I trust them, replace all internal links still pointing to the old domain, make sure Google can fetch my sitemap, check robots.txt and noindex tags, clean up the old platform’s mobile redirect mess, monitor 404 logs daily for the first week, run a single PageSpeed test and fix one critical issue, resubmit the sitemap, verify the redirects again after a week, and document everything for monthly reviews.
I learned this sequence when migrating dailingua.com from Blogger to a self‑hosted WordPress platform. The moment the domain resolved to the new server, every old Blogger URL immediately returned a 404. Ninety‑one pages that had been live, indexed, and slowly gaining search traction were suddenly dead ends. Googlebot was already on its way to recrawl, and the window between “domain live” and “first recrawl” is measured in hours, not days. What I did in that window determined whether my site’s search presence survived the move.
Before the migration, my analytics showed 1,370 total events in the previous month, with 112 active users spending an average of 3 minutes and 9 seconds on the site. The bounce rate was 0.498. Google had indexed fourteen of my pages. After the migration, the engagement metrics dropped total events fell to 387, active users to 76, session duration to 51 seconds, and bounce rate rose to 0.659 cut the indexed count jumped to 70 pages in a single update. The traffic dip was the expected re‑evaluation period. The redirect map ensured that every old link still worked, and the twelve immediate steps I took before Googlebot arrived made the difference between a temporary reset and a permanent loss.
This guide is the exact checklist I executed step by step, with real data and real results. Every action is grounded in what I did on dailingua.com, and every step can be replicated on any platform migration.
Step 1: Lock Your Permalink Structure Immediately
The first action I took after the domain pointed to the new server was to lock the permalink structure. On Blogger, my URLs had a date‑based format with an .html extension something like /YYYY/MM/article‑slug.html. The WordPress import had preserved that structure, but I did not want it. I wanted clean, human‑readable slugs that would never need to change again. A permalink structure that changes later creates a second wave of broken links, forcing another redirect map rebuild and confusing search engines. The old indexed URLs would need to redirect to yet another new URL, and the cycle of re‑evaluation would start again. I had already invested hours in building the redirect map; I was not going to risk a future change that would require another one.
I went to WordPress dashboard → Settings → Permalinks and changed the structure from the default “Day and name” to Post name (/%postname%/). After selecting the option, I clicked Save Changes twice. The first save updates the database. The second save flushes the rewrite rules and ensures no old date‑based URL structures linger in the cache. I verified the change by visiting several posts on the front end. Each one loaded with the new, clean slug. I also checked the source code of the homepage to confirm the canonical tags reflected the new structure.
The post‑name structure is the simplest permanent choice. It removes dates that make content look outdated, eliminates category base prefixes that can change, and produces the shortest possible URLs. A URL like /how-to-build-a-redirect-map/ works equally well today and five years from now. I avoid structures that include dates because they tie the URL to a specific moment. If I ever update an old article, the date in the URL becomes misleading. I avoid structures with categories because reorganizing categories later changes every URL. The post‑name structure is the only one that guarantees stability.
After the change, I cleared the LiteSpeed Cache (from the WordPress admin bar, LiteSpeed Cache → Toolbox → Purge All) and the hosting‑level cache in my hosting control panel to ensure no stale redirects remained. I also checked the SEO plugin’s canonical tag settings to ensure they were set to automatically use the new permalink structure. This step is non‑negotiable. Set the permalink structure once, set it correctly, and never touch it again the commitment to a stable foundation is what I apply to a self‑discipline system that keeps the entire site consistent.
· Go to WordPress dashboard → Settings → Permalinks and select “Post name.” This removes dates and produces clean, short URLs.
· Click Save Changes twice to flush rewrite rules. The first save updates the database; the second forces WordPress to regenerate URL mappings.
· Verify that a sample of posts load with the new, clean URLs. Open three random articles and confirm the address bar shows the post‑name format.
· Check the canonical tag in the page source to ensure it reflects the new structure. Right‑click → View Page Source, search for canonical, and confirm it matches the post‑name URL.
· Clear all caches (LiteSpeed Cache → Toolbox → Purge All and hosting‑level) to remove stale references.
· Never change the permalink structure again. Any future change will break every link on the site and require a second redirect map rebuild.
Step 2: Build and Import a Perfect Redirect Map
The old URLs had to send visitors and Googlebot to the new URLs with a 301 permanent redirect. If even one old link returned a 404, the traffic and ranking signals from that URL were lost. I tested the automated “Blogger to WordPress Redirection” plugin first. It relied on a custom field called blogger_permalink that the import process had not created. The plugin could not match any old URLs to new ones because the reference data it needed simply did not exist. I then tested the Redirection plugin’s regex import, but the slugs had been altered during the import for example, language-tips-village-to-5-languages-my-story became from-village-to-5-languages-my-story. No pattern could account for those inconsistent changes. The only reliable method was to build the map by hand.
The manual CSV method took several hours, but it was the only method that guaranteed every redirect was correct. I extracted every old URL from the Blogger XML backup file. I opened the file in a plain text editor and searched for the <link rel=’alternate’> tags. Each one contained an href attribute with the full old URL. I copied every one posts, pillar pages, legal pages into a plain‑text file. The final list had 91 old paths.
For each old URL, I opened the new WordPress site, located the matching post by content, and copied its permalink. I did not assume that the old slug and the new slug would match. I opened the content side by side the old article on the Blogger dashboard and the new article on the WordPress editor to confirm they were the same piece. I placed the old path and the new path side‑by‑side in a spreadsheet and saved it as a CSV file. The file used two columns: source and target. The source was the old relative path, exactly as it appeared in the old URL, including any encoded characters like %20. The target was the new relative path, with trailing slashes where appropriate. Example entries:
“`
source,target
/YYYY/mm/custom-permalinm-from-blogger-html,/clean-wordpress-custom-permalink/
I imported the CSV into the free Redirection plugin. The path in the WordPress dashboard is Tools → Redirection → Import/Export. The first attempt failed with an “Invalid group” error because the group didn’t exist. I created a new group under WordPress dashboard → Tools → Redirection → Groups by clicking “Add New” and naming it “Redirections,” then re‑imported the CSV. All 91 redirects appeared instantly. I then clicked on the group name to open its settings and verified that the default redirect type was set to 301 Moved Permanently. The manual CSV method is what I describe in how to build a full redirect map from old URLs to new ones.
· Extract every old URL from the old platform’s export file or sitemap. For Blogger, use the XML backup; for other platforms, use the built‑in export tool or a sitemap crawl.
· For each old URL, locate the matching new page and copy its permalink. Do not assume slugs match verify content manually.
· Create a two‑column CSV with source and target columns. The source is the old relative path; the target is the new relative path.
· Preserve encoded characters like %20 exactly as they appear in the old URL. The redirect rule matches the exact request string.
· Save the file with UTF‑8 encoding, comma delimiters, and no BOM. Open the CSV in a plain text editor to verify commas are used, not semicolons.
· In WordPress dashboard → Tools → Redirection → Groups, create a group named “Redirections.”
· Go to WordPress dashboard → Tools → Redirection → Import/Export, select the CSV, choose the group, and import.
· Verify that the default redirect type for the group is set to 301, not 302. This ensures all imported rules pass full link equity.
Step 3: Test Redirects Until You Trust Them
A CSV import can look successful while a single misplaced slash or wrong slug sends a link into a dead end. I had to verify every redirect before Googlebot did. I opened a private browser window to avoid cached redirects and manually tested 10 random old URLs from the list. I pasted each full old URL into the address bar and watched the result. Each one was instantly rewritten to the new URL, and the correct page loaded. I did not just glance at the address bar; I read the article content to confirm it was the right piece, not just the right URL.
I also opened the browser’s Developer Tools by pressing F12, clicked the Network tab, and confirmed the status code was 301 Moved Permanently. A 302, or any other response, would have been a failure because search engines treat a 302 as temporary and do not pass full link equity. I checked the response headers for each redirect to ensure the status line read HTTP/1.1 301 Moved Permanently or HTTP/2 301. Every tested redirect passed. I also checked the “Location” header in the response to confirm it matched the new URL I had mapped in the CSV.
One edge case was an old URL that contained an encoded space as %20. The CSV had preserved that exact encoding, and the redirect matched it correctly. If I had cleaned up the URL before adding it to the map, the redirect would have failed because the browser and bot request the exact encoded string. I also tested a URL with a trailing slash and one without, confirming that the Redirection plugin’s “ignore trailing slash” setting was handling the variation. I tested from a mobile browser to ensure no device‑specific caching interfered.
I also used curl from the command line to verify the HTTP headers. The command curl -I –location https://dailingua.com/old-path.html showed the full redirect chain and the final 200 response. This confirmed there were no intermediate 302 hops and that the final destination returned the correct content. I ran this on ten random URLs, and each returned a single 301 followed by a 200. The curl test is important because it bypasses the browser entirely, simulating how a search engine bot would see the response.
This testing discipline incognito window, network tab, curl verification is the only way to be certain the redirects will work for every visitor and every bot. I did not trust the import success message. I verified with my own eyes and tools. The evidence based approach is what I use when structuring a long‑form guide that readers can actually finish.
· Open a private/incognito browser window to avoid cached redirects. Your normal browser may have cached old 301s.
· Test a random sample of old URLs (at least 10). Copy the exact old URL from your CSV and paste it into the address bar.
· Confirm each redirect lands on the correct new page. Read the content to verify it matches the old article.
· Use the browser’s Network tab (F12) to verify the status code is 301. Look for the “Status” column and the “Location” header.
· Test edge cases: encoded spaces (%20), trailing slashes, URLs with and without www, mobile browser.
· Use curl -I –location <old-url> to check the response headers from the command line. This simulates a search engine bot.
· If any redirect returns a 302, edit the rule in Redirection to force 301. You can do this by opening the group settings and setting the default HTTP code to 301.
Step 4: Replace Every Internal Link That Still Points to the Old Domain
After the import, many of my articles still contained internal links pointing to the old Blogger domain https://dailingua.blogspot.com/…. Even if those old URLs redirected, each internal click forced a redirect hop, slowing readers and sending confused signals to search engines. Each redirect hop also dilutes a small amount of link equity. I needed to update every internal link to point directly to the new WordPress URLs.
I used a search‑and‑replace plugin to scan the entire database for the string dailingua.blogspot.com and replace it with dailingua.com. This single operation updated dozens of internal links across posts and pages, eliminating the unnecessary redirect hop. After the replacement, I went back to WordPress dashboard → Settings → Permalinks and clicked Save Changes to flush any cached rewrite rules that might still reference the old domain. This step ensures that WordPress regenerates its internal URL mappings and does not serve stale redirects.
The bulk replacement is fast, but I did not trust it blindly. I manually opened the four pillar pages my most important content hubs and checked every internal link they contained. I clicked each link to confirm it resolved to the correct new URL without a redirect hop. I found one link that had been missed because the old URL was using an https:// prefix with a different subdomain variant. I updated it manually. I also checked the anchor text of each link. The bulk replacement preserves the original anchor text, but I wanted to ensure that phrases like “click here” were replaced with descriptive text. I updated several links to use more descriptive anchor text, such as changing “click here” to “my guide to building a redirect map.” This improves both user experience and the relevance signals that search engines use to understand what the linked page is about.
When Googlebot crawls a page and follows an internal link that redirects, it wastes crawl budget on the redirect hop instead of discovering new content. By updating every internal link to point directly to the new URL, I gave Googlebot a clean, efficient path through the site. This improved the crawl rate and helped the new URLs get indexed faster. The thoroughness is what I apply when keeping old articles fresh through regular editing routines.
· Use a search‑and‑replace plugin to replace the old domain with the new domain in the entire database. Search for the exact old domain string, including https://.
· After replacement, go to WordPress dashboard → Settings → Permalinks and click Save Changes to flush rewrite rules. This regenerates WordPress’s internal URL mappings.
· Manually inspect high‑value pages (pillar pages, most‑linked posts) for any missed old‑domain links. Click each link to test it.
· Update anchor text where it is generic to use descriptive, keyword‑rich phrases. This improves both user experience and SEO.
· Click through a sample of updated links to confirm they resolve directly without a redirect hop. Use the Network tab to verify a direct 200 response, not a 301.
Step 5: Make Sure Google Can Fetch Your Sitemap
The sitemap is the fastest way for Googlebot to discover the new URLs. If Google cannot access the sitemap, it will eventually crawl the site through links, but the process will be slow and incomplete. My SEO plugin generated the sitemap in a browser, it loaded correctly, listing three sub‑sitemaps. But when I submitted it to Google Search Console, the status said “Couldn’t fetch.” The URL Inspection live test returned a generic “Something went wrong.”
The cause was not immediately obvious. I checked the following:
· robots.txt – I checked my it contained a Sitemap: directive pointing to the sitemap index and no Disallow: rules that would block crawling.
· Hosting control panel – no IP blocks or security rules that would filter Googlebot.
· Security plugins – deactivated temporarily, no change in the fetch status.
· Direct browser access the sitemap loaded correctly for me, meaning the file was generated and the URL was valid.
The fix came after I contacted my hosting provider’s support team and described the issue in detail. They investigated the server‑side ModSecurity firewall and found a rule that was blocking requests from Googlebot when the URL ended in .xml. The rule had been configured to protect against malicious XML‑based attacks but was too broad. They adjusted the rule to whitelist Googlebot for sitemap URLs. Immediately after the adjustment, I returned to Search Console, used the URL Inspection tool on the sitemap URL, and clicked Request Indexing. The sitemap loaded successfully, and the status changed to “Success” within minutes.
The sitemap is the fastest way for Googlebot to discover the new URLs. If Google cannot access the sitemap, the recrawl will be slow and incomplete. This experience taught me that some migration problems live outside the site itself. The hosting environment, server‑level firewalls, and security configurations must be part of the diagnostic process. When a sitemap fails to fetch despite being valid in a browser, the next step is to contact the host and ask them to check server logs. The lesson is central to recovering search traffic after any kind of platform change.
· Locate your sitemap URL (usually /sitemap_index.xml or /sitemap.xml). Check your SEO plugin’s settings to find the exact URL.
· In Google Search Console → Sitemaps, submit the sitemap URL. Enter the full URL and click Submit.
· If the status shows “Couldn’t fetch,” check robots.txt for Disallow rules that might block crawling. Visit yourdomain.com/robots.txt to review.
· Temporarily disable security plugins and retest. Some security plugins block bot access to XML files.
· Test the sitemap URL directly in a browser; if it loads but Search Console still fails, contact your hosting provider. Describe the issue and ask them to check ModSecurity or other firewall rules.
· After the fix, use the URL Inspection tool in Search Console to confirm the sitemap is accessible. Click Request Indexing to prompt a fresh crawl.
Step 6: Check Robots.txt and Noindex Tags
A single rogue Disallow rule in robots.txt or a noindex tag left over from a staging environment can prevent the entire site from being indexed. I visited https://yourdomain.com/robots.txt and confirmed it contained only a Sitemap: line pointing to the sitemap index and no Disallow rules that would block search engines. The file looked exactly as expected: a clean directive telling bots where to find the sitemap, with no restrictions.
I then spot‑checked several important posts by viewing the page source and searching for the word noindex. None were found. The SEO plugin’s global settings were also confirmed to allow indexing of posts, pages, and categories. I checked the WordPress dashboard → Settings → Reading page to ensure the “Discourage search engines from indexing this site” checkbox was unchecked a common setting left over from development or staging environments. If that box had been checked, Google would have ignored the entire site, and my indexed count would have dropped to zero within days.
Beyond the page source, I checked the HTTP response headers using curl -I. Some security plugins inject a X-Robots-Tag: noindex header that does not appear in the HTML source. I ran the command on my homepage and several posts and confirmed no such header was present. This extra check caught a potential issue on a staging site I later worked on, where a security plugin had been configured to block indexing during development and the setting had survived the migration.
I also checked the per‑category and per‑tag noindex settings in the SEO plugin. My main categories were set to index. Author archives were set to noindex by default this was intentional, as author pages on a single‑author blog do not add value in search results. The important thing was that no critical content was accidentally blocked. This check took less than five minutes but is one of the highest‑impact verifications in the entire checklist of verifying every configuration is what I apply to choosing a WordPress theme that will not slow down the site.
· Visit https://yourdomain.com/robots.txt and confirm no Disallow: / rules. The file should be clean, with only a Sitemap directive.
· View the page source of your homepage and key posts; search for noindex. Use Ctrl+F or Cmd+F to search.
· Check the SEO plugin’s global settings to ensure indexing is enabled for posts and pages. In Rank Math, go to Titles & Meta → Post Types.
· In WordPress dashboard → Settings → Reading, ensure “Discourage search engines” is unchecked. This is a common staging‑site leftover.
· Use curl -I <url> to check for X-Robots-Tag: noindex in HTTP headers. This catches noindex tags that don’t appear in the HTML.
· Spot‑check category and tag pages for accidental noindex settings. In your SEO plugin, review the settings for each taxonomy.
Step 7: Clean Up the Old Platform’s Mobile Redirect Mess
Blogger had created duplicate mobile versions of every post with ?m=1 appended to the URL. When a visitor on a mobile device accessed a Blogger page, the platform automatically redirected them to a version with ?m=1 in the URL. Google had indexed many of those mobile‑specific URLs as separate pages. After the migration, those URLs were returning 404s because the new WordPress site had no ?m=1 parameter.
I added a regex redirect in the Redirection plugin to handle any URL that ended with ?m=1. In the plugin, I went to WordPress dashboard → Tools → Redirection → Add New and created a rule with:
· Source: /(.*)\?m=1
· Target: /$1/
· Regex checkbox enabled.
This rule matches any path that ends with the mobile parameter, captures everything before the question mark, and redirects to the clean URL without the parameter. After adding the rule, I tested several old ?m=1 URLs in an incognito window. Each one redirected correctly to the clean post slug, stripping the mobile parameter. I also tested the encoded version (%3Fm%3D1) to ensure the regex handled both variants. I tested a URL with additional query parameters, like ?m=1&utm_source=twitter, and the regex still matched because it captures everything before ?m=1.
Blogger’s ?m=1 parameter is an example of a platform‑specific quirk that can cause post‑migration 404s if not addressed. Every platform has its own quirks: some generate session IDs in URLs, others append tracking parameters, and others create printer‑friendly versions. During the URL extraction phase, I looked for any patterns in the old URLs that differed from the standard structure, and I created specific rules for each. The regex rule is the most efficient way to handle parameter‑based variants because one rule covers every URL.
This single rule covered every mobile variant Google may have previously crawled. Without it, those mobile‑specific indexed URLs would have become dead ends, and the ranking signals they carried would have been lost. The attention to platform‑specific quirks is what I discuss in how to diagnose and fix common WordPress migration bugs.
· Identify any mobile‑specific URL patterns from the old platform (e.g., ?m=1, /mobile/, m. subdomain). Check your old sitemap or Search Console data for indexed mobile URLs.
· In WordPress dashboard → Tools → Redirection → Add New, create a regex redirect rule that strips the mobile parameter and points to the canonical URL. The source should capture the path and the parameter; the target should use only the captured path.
· Test the rule with the exact old mobile URL, including encoded versions. Use an incognito window.
· Check Google Search Console for any indexed URLs containing the mobile parameter. Use the Performance report filtered by Pages and search for ?m=1.
· Document the regex rule for future reference. Save the source and target patterns in your migration documentation.
Step 8: Monitor 404 Logs Daily for the First Week
Even with a careful redirect map, some URLs will be missed. They might be old tag pages, RSS feed variants, or links from obscure corners of the web. If I caught them quickly and added redirects, they would never become permanent dead ends. For the first seven days after migration, I opened the Redirection plugin’s 404 Log each day. The log is located at WordPress dashboard → Tools → Redirection → Logs → 404 Errors. The log shows every incoming request that did not match a redirect rule or a live page, along with the referring URL and the user agent.
The first day showed a few hits from old tag archive pages URLs like /search/label/learning that Blogger had generated but I had not included in the redirect map. There was also a hit from an old test post I had forgotten existed. For each one, I identified the most relevant new page usually the blog index or a category page and added a manual redirect using the Redirection plugin’s Add New function. If a relevant page existed, I pointed the old URL there. If not, I redirected to the blog index as a catch‑all.
I sorted the 404 log by hit count the URLs with the most hits were the highest priority because they represented real visitors or bots encountering dead ends. The URLs with a single hit from an obscure referrer were lower priority, but I still added redirects for them to keep the log clean. By the fourth day, the 404 log showed zero entries originating from old Blogger paths. I continued monitoring for another three days to be sure, then switched to a weekly check.
The daily 404 log check caught three additional redirects that would have otherwise become permanent dead ends. I also set up Google Search Console to send me an email if a significant number of 404 errors were detected. This alert would catch any sudden spike that I might miss between manual checks. The alert arrived once during the first week when a misconfigured social media link pointed to an old URL I had missed. I added the redirect within minutes. This daily discipline caught three additional redirects that would have otherwise become permanent 404s, and it gave me confidence that the redirect map was complete the habit of daily monitoring is what I use in a daily blogging routine that keeps the work feeling normal.
· Open the Redirection plugin’s 404 Log at WordPress dashboard → Tools → Redirection → Logs → 404 Errors every day for the first week.
· Sort by hit count to prioritize the most frequent 404s. The URLs with the most hits should be fixed first.
· For each 404, identify the best matching new page and create a manual redirect using the Add New button.
· If no relevant page exists, redirect to the blog index or a category page. A soft 404 (redirect to homepage for irrelevant content) is better than a hard 404.
· Set up email alerts in Google Search Console for spikes in 404 errors. Go to Settings → Preferences → Email Notifications.
· After a week of zero old‑platform 404s, switch to a weekly check. Continue monitoring monthly thereafter.
Step 9: Run a Single PageSpeed Test and Fix One Critical Issue
Google considers page speed as a ranking factor, but a slow site hurts user experience immediately after migration. I did not need a perfect score on the first day, but I needed to catch any catastrophic slowdown that would cause visitors to leave before the page loaded. I ran a PageSpeed Insights test on a single article the same article I had tested before the migration. The mobile score was 87, with Largest Contentful Paint at 3.9 seconds. The LCP had nearly doubled from the pre‑migration baseline of 1.7 seconds.
I did not try to fix everything at once. I opened the PageSpeed report and looked at the “Diagnostics” section to find the single largest bottleneck. The report showed that the featured image the LCP element was being lazy‑loaded. Lazy loading tells the browser to delay loading an image until it is about to scroll into view. For the featured image at the top of the post, this meant the browser was waiting until after the entire page was interactive before it even started fetching the most important visual element. That single setting was adding approximately two seconds to the LCP.
I went to WordPress dashboard → LiteSpeed Cache → Page Optimization → Media Settings and set Lazy Load Images to OFF. I purged all caches both in LiteSpeed Cache (using LiteSpeed Cache → Toolbox → Purge All) and in the hosting control panel and retested. The mobile score jumped from 87 to 94, and the LCP dropped from 3.9 seconds to 2.1 seconds. That one change gave Googlebot a fast‑loading page on its first recrawl. Further fine‑tuning including preloading the featured image, removing bloated plugins, and adding code snippets brought the score to 98 later. The full sequence is documented in how to set up page speed settings that took my mobile score from 87 to 98 the key lesson for the immediate post‑migration window is to fix the single biggest bottleneck, not to chase perfection.
If the LCP is already under 2.5 seconds but the score is still below 90, I check the “Opportunities” section for the next largest improvement. Common culprits after migration include render‑blocking CSS from a new theme, unoptimized images imported from the old platform, or a plugin injecting heavy JavaScript. The diagnostic framework identify the bottleneck, fix it, retest applies to any performance issue. The goal in the immediate post‑migration window is not a perfect score. The goal is a score above 90 that gives Googlebot a fast enough page to evaluate the site positively. The rest can be optimized over the following weeks.
· Run a PageSpeed Insights test on a single article (mobile tab). Use the URL of your most representative post.
· Identify the LCP element in the Diagnostics section. Look for “Largest Contentful Paint element” and click to see which image or text block is being measured.
· Check if the LCP element is being lazy‑loaded; if so, turn off lazy loading at WordPress dashboard → LiteSpeed Cache → Page Optimization → Media Settings. Set Lazy Load Images to OFF, or add the LCP element’s class to the exclusion list.
· Purge all caches (LiteSpeed Cache → Toolbox → Purge All and hosting‑level) before retesting. Cached pages may still serve the old, slow version.
· Aim for a score above 90 and LCP under 2.5 seconds; do not chase perfection in this window. Fix the biggest bottleneck and move on.
· If LCP is fine, check the “Opportunities” section for the next largest bottleneck. Look for “Eliminate render‑blocking resources” or “Reduce unused JavaScript.”
Step 10: Resubmit Your Sitemap and Watch the Index Surge
After all the fixes redirects in place, sitemap fetchable, internal links cleaned, noindex tags removed, mobile redirects handled I needed to explicitly ask Google to recrawl the site. The sitemap submission is that request. In Google Search Console, I deleted the old sitemap submission (which still showed the “Couldn’t fetch” error) and submitted my sitemap fresh.
Within a day, the status changed from “Couldn’t fetch” to “Success.” The sitemap index reported 91 discovered pages exactly the number of posts, pages, and other content I had migrated. Two days later, I checked the Index Coverage report. The number of indexed pages had jumped from 14 to 70 in a single update. The remaining pages were either new or in the process of being evaluated.
The Index Coverage report breaks pages into categories: “Indexed,” “Not Indexed,” and “Warning.” After the sitemap resubmission, I checked each category. The “Not Indexed” section included “Discovered – currently not indexed” for newer pages and “Crawled – currently not indexed” for pages Google had visited but not yet included. This is normal for a new site. Google takes time to evaluate quality before adding pages to the main index. The “Warning” section initially showed “Page with redirect” for the old URLs that were now 301‑ing to the new ones. This is also expected Google is recrawling the old URLs and discovering the redirects. Over the following week, these warnings cleared as Google updated its index.
I did not need to resubmit the sitemap again unless I made significant structural changes. Google recrawls the sitemap periodically on its own. But if I had added a large number of new pages or made another round of fixes, I would resubmit to accelerate the discovery. The sitemap submission is a signal, not a guarantee, but it shortens the time between the fix and the recrawl. This jump was the direct payoff of every step taken before Googlebot had a chance to recrawl a broken site the principle of trusting the process after doing the work is what I discuss in understanding why early blog posts need time to gain traction.
· In Google Search Console → Sitemaps, delete the old sitemap submission. This clears the error state and allows a fresh submission.
· Submit the sitemap URL fresh. Enter the full URL and click Submit.
· Wait 24–48 hours and check the status; it should change to “Success.” Do not resubmit repeatedly patience is key.
· Check the Index Coverage report in Search Console for a jump in indexed pages. Look under the “Indexed” count.
· Note that “Page with redirect” warnings are normal during the transition. They will clear as Google follows the 301s.
· Monitor the report weekly; resubmit only if major structural changes occur. The sitemap will be crawled automatically thereafter.
Step 11: Verify That All Redirects Are Still Working After the First Week
After the initial 404 monitoring period, I conducted a more thorough redirect audit. The 404 log had been clean for several days, but I wanted to confirm that no redirect rules had been accidentally modified or deleted during the content updates I had made during the week. I exported the list of all 91 redirect rules from the Redirection plugin using WordPress dashboard → Tools → Redirection → Import/Export → Export and tested a random sample of 20 old URLs in an incognito window.
I also used a command‑line tool to check the HTTP response headers for each redirect. The command curl -I –location old-url showed the full redirect chain and the final response code. Every tested redirect returned a single 301 with no intermediate hops. One redirect had been affected when I changed a post slug. The old URL was still pointing to the new slug correctly, but a cached version of the page on my local machine had shown a 404 during initial testing. I cleared the browser cache, retested, and the redirect worked perfectly. This taught me that browser cache can sometimes show a 404 even when the redirect is functioning, which is why curl is a more reliable testing tool.
I created a simple spreadsheet with columns for the old URL, the new URL, the HTTP status code, and any notes. I filled it in as I tested the 20 random URLs. This audit log gave me a dated record of the verification, which I saved alongside the original CSV. If a redirect ever broke in the future, I could compare the current state against the audit log. The audit log is also useful for troubleshooting if a specific old URL stops working I can check whether the redirect rule still exists or if it was accidentally deleted.
This audit confirmed that the redirect map was not only complete at the time of import, but still intact after several days of content updates. I now include this verification step in every migration, because post‑launch edits can sometimes overwrite or conflict with redirect rules. For example, if I change a post slug, the old slug might still redirect to the new one, but if I later delete the redirect rule to clean up, I need to ensure the old URL is still covered by a different rule. The audit catches these edge cases. The regular auditing is what I apply to staying consistent with the habits that keep a site growing over the long term.
· Export the list of all redirect rules from WordPress dashboard → Tools → Redirection → Import/Export → Export. Save the file for reference.
· Test a random sample (at least 20) in an incognito window. Select URLs from different content types: posts, pages, mobile variants.
· Use curl -I –location <old-url> to confirm 301 status and no redirect chains. A single 301 followed by a 200 is ideal.
· Create a redirect audit log with old URL, new URL, status code, and notes. Save this as a spreadsheet alongside your original CSV.
· Save the audit log alongside the original CSV for future reference. This becomes your permanent record of the migration.
· Repeat this audit after any major content update. If you change slugs or delete pages, verify that old URLs still resolve.
Step 12: Document Every Change and Set a Monthly Review
The final step in my immediate post‑migration checklist was to document every change I had made. I created a dedicated folder on my computer and saved the following:
· The final CSV file with all 91 redirect mappings.
· A text file noting the permalink structure setting (/%postname%/).
· The sitemap URL and the date it was successfully fetched.
· The regex rule for ?m=1 URLs, including the exact source and target patterns.
· Notes from the 404 log, including the three additional redirects I added during the week.
· The PageSpeed Insights report showing the score before and after the lazy‑loading fix.
· The redirect audit log from Step 11.
The documentation serves as a permanent record of the migration. If a future change causes a problem, I can refer back to the original configuration and restore it quickly. I also set a recurring monthly calendar reminder to review three things: the Redirection plugin’s 404 log at WordPress dashboard → Tools → Redirection → Logs → 404 Errors, the Search Console Index Coverage report, and a PageSpeed test on the top three most‑visited articles. This monthly review takes less than fifteen minutes and ensures that no new broken links, crawl errors, or speed degradations accumulate over time.
My monthly review follows a simple sequence:
1. Open the Redirection plugin and check the 404 log at WordPress dashboard → Tools → Redirection → Logs → 404 Errors. If any new broken links appear, add redirects.
2. Open Google Search Console and review the Index Coverage report. Look for any new errors or warnings.
3. Run PageSpeed Insights on the top three articles. If any score drops below 90, investigate the cause.
4. Check the installed plugins list for any that have been updated. If a plugin update added new scripts, test again.
5. Verify a random sample of five redirects using an incognito window.
This monthly routine has kept my site stable through multiple plugin updates and content additions. The documentation serves as a permanent record of the migration. If a future change causes a problem, I can refer back to the original configuration and restore it quickly. If I ever migrate again, I have a complete template to follow. The habit of documentation is what I use when writing through doubt and technical challenges without stopping.
· Save all migration artifacts: CSV, permalink setting, sitemap URL, regex rules, 404 log notes, PageSpeed reports, audit log. Store them in a dedicated folder, backed up to cloud storage.
· Set a recurring monthly calendar reminder. Use your calendar app with a specific description of what to review.
· Monthly review: check 404 log at WordPress dashboard → Tools → Redirection → Logs → 404 Errors, Search Console Index Coverage, PageSpeed (top 3 articles). Each check takes only a few minutes.
· Verify a random sample of 5 redirects each month. Use an incognito window and confirm 301 status.
· Update documentation if any changes are made. If you add new redirects or change a setting, note it in the master document.
The Waiting Period: How to Interpret the Temporary Traffic Dip
After completing the twelve steps, the analytics showed a sharp drop. Total events fell from 1,370 to 387. Active users from 112 to 76. Session duration from 3 minutes and 9 seconds to 51 seconds. Bounce rate from 0.498 to 0.659. This is the normal re‑evaluation period. Google is recrawling the old URLs, following the 301 redirects, and assessing the new pages. During this time, some old rankings fluctuate, and some new pages are not yet fully indexed. The engagement metrics drop because the redirects themselves add a small delay, and because returning visitors may be disoriented by the new design.
The dip is temporary it does not indicate that the migration failed. It indicates that the search engine is processing the change. For my site, the engagement metrics began to recover within two weeks. The session duration gradually climbed back above one minute, then above two minutes, as readers adjusted to the new site and Google assigned stable rankings to the new URLs. I did not make any panic changes during this period. I trusted that the redirect map was working, the sitemap was being crawled, and the content was intact. The patience is what I apply to building a content cadence that sustains a site through every phase of its growth.
The Dailingua Payoff: From 14 Indexed Pages to 70 in One Update
The steps above are not hypothetical. They are the exact sequence that preserved my site’s search presence and accelerated its growth. The redirect map kept every old link alive. The sitemap fix unblocked Googlebot. The internal link cleanup removed redirect hops. The 404 monitoring caught the last stray URLs. The mobile redirect rule handled every ?m=1 variant. The PageSpeed fix gave Googlebot a fast first impression. The post‑week redirect audit confirmed the map was intact. And the documentation ensured the lessons were preserved.
The results were measurable. Before the migration, my site had 14 indexed pages on Google. After completing the twelve immediate steps and resubmitting the sitemap, the indexed count jumped to 70 pages in a single update. The engagement metrics eventually stabilized as the re‑evaluation period ended, and the site’s search traffic began to grow from the new, stronger foundation. While my own migration was from Blogger to WordPress, the framework applies universally. Whether you are moving from any closed platform to a self‑hosted one, from one content management system to another, or from an old domain to a new one, the vulnerabilities are the same: broken URLs, lost internal links, blocked sitemaps, hidden noindex tags, and slow first impressions. The twelve steps address each of these vulnerabilities directly.
The work I did in the hours after the domain resolved determined whether my site survived the move. The checklist I followed lock permalinks, build the redirect map, test redirects, replace internal links, fix the sitemap, check robots.txt, clean up mobile redirects, monitor 404 logs, fix one speed issue, resubmit the sitemap, verify redirects after a week, and document everything is now my permanent protocol for any platform migration. Each step addresses a specific vulnerability that can cause search traffic to evaporate during the critical recrawl window. By executing them immediately, before Googlebot arrives, I gave my site the best possible chance to emerge from the migration stronger than it entered.
Every future article, every backlink earned, and every new reader will benefit from the foundation laid in those first hours after the domain resolved. Do these twelve steps immediately after your migration, and you will never fear a platform move again.
The Long‑Term Maintenance Mindset
The twelve steps I completed in the first hours and days after the migration were the foundation. But the real long‑term success came from the monthly review habit I established in Step 12. A migration is not a single event that ends when the sitemap is submitted. It is the beginning of a new phase of site ownership, where the platform you control gives you more power and more responsibility. Every plugin update, every new article, every design tweak has the potential to affect the redirect map, the page speed, or the indexation status. The monthly review is the habit that catches those slow degradations before they become problems.
I have now kept this monthly routine since the migration. The 404 log has remained clean. The search traffic has grown steadily. The page speed has stayed at 98 on mobile and 100 on desktop. The redirect map has been updated whenever I changed a slug or consolidated two articles. The documentation I saved on the day of the migration has been referenced multiple times, each time saving me hours of re‑diagnosis. The twelve immediate steps were the sprint; the monthly review is the marathon.
A Universal Framework for Any Platform Move
This framework is not dependent on any specific platform. I migrated from Blogger to WordPress, but the same steps apply if you are moving from Wix, Squarespace, Joomla, Drupal, or any other system to a new one. The old platform’s export file gives you the old URLs. The new platform’s permalink settings give you the new URLs. The redirect plugin or server configuration handles the 301s. The sitemap URL is always in the same format: yourdomain.com/sitemap_index.xml or yourdomain.com/sitemap.xml. Google Search Console is the same for every site. The principles are universal.
What changes from platform to platform are the specific quirks: the mobile URL parameters, the date‑based permalink structures, the encoded characters, the hidden pages like tag archives or RSS feeds. That is why the manual verification in Steps 2 and 3 is so critical. Automated tools can handle the bulk of a migration when the URL structures are predictable. But when the slugs change, or when the platform has generated obscure URL variants, the only guarantee is a human checking each mapping. The hours I spent building the CSV and testing the redirects were the hours that prevented a cascade of 404s. That work is the same regardless of the platforms involved.
If I were to migrate again tomorrow, I would follow this same twelve‑step checklist without hesitation. I would lock the permalinks first. I would build the redirect map by hand, testing as I go. I would replace every internal link, fix the sitemap, check for noindex, handle mobile variants, monitor 404 logs, fix one speed issue, resubmit the sitemap, verify the redirects after a week, and document everything. The checklist is my permanent migration companion. It has served me once on dailingua.com, and it will serve me on any future site I build or move.
Your migration will have its own quirks and its own challenges, but the twelve steps will guide you through them. Start the moment the domain resolves, work through each step before Googlebot arrives, and trust the process during the re‑evaluation period. The reward a site that emerges from migration faster, cleaner, and more search‑visible than it was before is worth every minute of the work.