The day I moved my site from Blogger to a self‑hosted WordPress setup, I finished importing the content, pointed the domain to the new server, and opened a browser to test a few old URLs. Several returned “404 Not Found.” At that moment I understood the redirect problem completely: unless every single old address is pointed to its new home, every backlink, every bookmark, every search result that took months to earn simply vanishes.
I sat down with a simple spreadsheet, extracted every URL I could find from the old platform, and built a manual CSV file that eventually redirected every old link to the correct new page. That experience became the foundation for the system I describe in this guide.
The method I share here is not tied to any specific platform. Whether you are leaving Blogger, WordPress.com, Squarespace, Wix, or any other content management system, the steps for building a complete redirect map are the same. I use my own migration from Blogger to WordPress to demonstrate exactly how I handled each step what I did, what I learned, and what I would do for any platform change. What follows is the process I now follow whenever I need to preserve every backlink, prevent 404 errors, and ensure a new site picks up precisely where the old one left off.
Why Redirects Are Non‑Negotiable and What Happens When You Skip Them
A platform change almost always changes the structure of your site’s addresses. Blogger adds date‑based folders and .html extensions to post URLs; a self‑hosted WordPress site may use clean slugs like /post‑name/. The moment you switch, every old URL that was ever indexed, linked, or saved stops working unless you create a permanent redirect from the old address to the new one. Skipping this step means losing all the backlinks that other sites have placed to your content.
Those links, however modest, were building your site’s authority with search engines. It means search engines drop your pages from their index because the old URLs return errors, and any rankings you had earned disappear. It means visitors who click an old social media post, a pinned bookmark, or a link from another site land on an error page, and trust in your site erodes.
A proper redirect tells both users and search engines that the content has moved permanently. For search engines, a 301 status code signals that all ranking signals should be transferred to the new address. For users, the transition is invisible; they click the old link and arrive at the correct article without ever seeing an error.
This is not an optional step; it is the single most important technical task after any platform migration. Without it, the new site starts from zero, rebuilding authority that was already earned that foundational work of preserving what you have already built is central to recovering search traffic after a platform migration instead of watching it disappear.
The Two Approaches Automatic Plugins Versus Manual CSV Map
There are two ways to create redirects after a migration. The first is to use an automatic redirect plugin that promises to scan your old site, compare it with the new one, and generate redirects automatically. These tools rely on matching content titles, slugs, or custom fields. The second is to build a manual CSV map: a simple spreadsheet with two columns, old URL and new URL, which you then import into a redirect management tool. I tried both during my own migration. The automatic approach sounded faster, but it failed.
The manual CSV method took more effort at the start, yet it proved fully reliable and works in every situation. In this guide, I show you both approaches and explain exactly how to fall back to the manual method when the automatic one does not work because in most real‑world migrations, it does not.
When Automatic Redirect Plugins Fail What I Saw Firsthand
When I first attempted the migration for my site, I tried a popular plugin that claimed to generate redirects automatically from the old Blogger data. It looked for a specific custom field that was supposed to hold the old permalink, but during the import process, that field had not been created. The plugin found nothing to work with.
I then tried a regex‑based import inside the Redirection plugin. It could match some old URL patterns like /YYYY/MM/url‑post.html but only when the new slug was exactly identical to the old one. During the content import, WordPress had cleaned up many slugs, shortening long ones and dropping certain words. For example, an old slug that originally read language‑tips‑village‑to‑5‑languages‑my‑story became from‑village‑to‑5‑languages‑my‑story. The regex pattern could not account for these individual changes.
The lesson was clear real methods are fragile. They only succeed when old and new URLs follow a perfectly predictable pattern. In most actual migrations, manual pairing is the only reliable path. On my site, there were 82 articles and several static pages a total of 91 unique pages that needed a 301 redirect. Each one had to be matched individually because the slugs shifted in unpredictable ways during the import. No plugin could handle that variation.
The Manual CSV Method The Solution That Never Fails
The manual CSV method is straightforward: I create a plain text file with two columns, source and target, listing every old URL and its matching new URL. I then import this file into a redirect plugin. Because I have verified every pair myself, there are no surprises. The process might take an hour or two for a smaller site, but it guarantees zero 404 errors from old content.
In the steps that follow, I will walk through the entire sequence: extracting every old URL, finding their new equivalents, formatting the CSV correctly, importing it, testing, and maintaining the redirect file for the long term. The method works regardless of whether your old platform was Blogger, a different hosted service, a self‑hosted installation, or a completely custom‑built site.
Step 1: Extract Every Old URL From Your Current Platform
Before I can redirect anything, I need a complete list of every URL that ever existed on the old site. Where I get them depends on the platform I am leaving. For Blogger, I go to Settings, then Back up content, and save the file to my computer; I open the downloaded XML file in a text editor and look for the <link rel=’alternate’ href=’…’> tag inside each post and page entry. I copy every URL into a simple list. For my site, this gave me the 82 article URLs plus the page URLs 91 total.
For a self‑hosted WordPress site, I use the built‑in export tool under Tools → Export, or I crawl the site with a free desktop crawler that can extract all URLs. Many crawlers can export a list of URLs as a plain text file, which I then clean up and sort. For a platform like Squarespace or Wix, the approach is similar: Squarespace allows exporting content as a CSV, and Wix provides an export file that includes page URLs.
If the old platform generated a sitemap, that file often contains every URL that was submitted to search engines, and I can download it directly by visiting yourdomain.com/sitemap.xml. If the old site is no longer accessible, the Wayback Machine at archive.org can provide historical snapshots, and a backlink checker can reveal which old URLs still receive links from other sites.
I collect every URL posts, pages, archive pages, RSS feeds if they were indexed. I write them all into a simple text file, one per line. This is the raw material for my redirect plan. If the site has a large number of URLs, I split the list into manageable batches of 200–300 to avoid feeling overwhelmed.
Step 2: Identify the Matching New URLs Without Guessing
Now I need the new destination for each old URL. My new site must be live and fully populated with content before I begin this step. I open my new site’s admin area and go to the list of all posts; I see each post’s slug, which is the last part of its URL. For pages, I go to the pages list. If I am uncertain about a match, I open the old content, if still accessible, and the new content side by side to confirm they are the same article. This manual verification is what makes the CSV method completely reliable.
On my site, some slugs had changed during import. For example, a post originally titled “How I became my own teacher” had a Blogger URL like 2026/03/self-education-tips-how-i-became-my-own-teacher.html , but WordPress truncated the slug to /self-education-tips-how-i-became-my-own-teacher-my-story/. I had to pair them manually to ensure accuracy.
If an old page was intentionally merged into a newer, combined article, I redirect the old URL to that combined page. If a page was deleted with no replacement, I redirect it to a closely related article or, as a last resort, to the main blog page. I avoid mass redirects to the homepage because that creates a poor experience for someone expecting a specific answer.
I create a two‑column spreadsheet with the old URL in the first column and the new URL in the second. This is the core of my redirect file. For larger migrations, I use spreadsheet formulas to help match slugs. For instance, if the old and new slugs are identical except for the date folder and extension, I can extract the slug from the old URL using text functions, construct the new URL pattern, and then manually verify the matches that the formula suggests.
Step 3: Build the Perfect CSV File With Correct Format and Encoding
The CSV file I will import must follow strict formatting rules. The first line must be the header: source,target with no spaces. Both the source and target should contain only the relative path of the URL, starting with a forward slash. I do not include the domain name; for example, I use /YYYY/MM/self-education-tips-how-i-became-my-own-teacher.html not the full web address. If my new site uses trailing slashes in its permalinks, every target must end with a /. I stay consistent.
If an old URL contains a space, it may be encoded as %20 in the original link; I keep it as %20 in the source field and do not decode it. I save the file as UTF‑8 without BOM encoding. I use a plain text editor; spreadsheet applications like Excel can change the encoding or add hidden characters. The delimiter must be a comma, not a semicolon. If an old URL happens to contain a comma, I wrap that entire field in double quotes.
If the old URLs have multiple query parameters for example, ?m=1&ref=feed I decide whether to strip the parameters via a separate regex rule or include the full parameter string in the CSV source. In my case, I handled the ?m=1 mobile parameter with a single regex rule, which I explain in Step 7, because it applied to every post. But for unique parameters, I include the full string in the CSV.
A valid CSV looks like:
source,target
/YYYY/MM/blogger‑custom‑permalink.html,/new‑wordpress‑custom‑permalink/
For my 91 URLs, the CSV had exactly 91 data rows plus the header. I used a plain text editor to save it, ensuring no extra spaces or encoding issues. I also added a few comment lines starting with # to document the date and migration type; the Redirection plugin ignores these lines during import.
Step 4: Import the CSV Into the Redirection Plugin
The free Redirection plugin is the tool I rely on for managing redirects. After installing and activating it, I go to Tools → Redirection → Import / Export. I click “Choose File” and select my CSV. Under “Column mapping,” I ensure that Source URL is set to the source column and Target URL to the target column. For the Group, I select “Redirections.” If that group does not exist, I go to Redirection → Groups and create it first, then return to the import screen. I click Import. If I see an error saying “0 redirects imported,” the cause is usually a wrong delimiter or a missing header row. I open the CSV in a plain text editor, confirm that commas separate the fields, and try again. Once the import completes, all my manual redirects are active.
On my site, the import of 91 redirects took only seconds. The plugin displayed a success message listing the count. I then immediately moved to testing. For sites with a larger number of redirects, I split the CSV into smaller files of 500 rows each and import them sequentially. The plugin skips duplicates if I include the same header in each file. This approach also makes it easier to isolate any problem rows if one batch fails, I can focus on those 500 entries rather than searching through thousands.
Step 5: Test Your Redirects Like a Search Engine Would
After importing, I must verify that the redirects actually work. I do not rely on the plugin’s logs alone. I open a private or incognito browser window so that no cached redirects interfere with the test. I pick ten to fifteen old URLs at random from my CSV, covering posts, pages, and any URLs with special characters. I paste each full old URL into the address bar and press Enter.
I should be redirected instantly to the new URL, and the browser’s address bar should show the new location. If I am comfortable with browser developer tools, I open the Network tab, reload the old URL, and confirm that the first response has a 301 Moved Permanently status code.
If any redirect fails, I double‑check the source path in the Redirection plugin and the target slug for a missing slash or a typo. During my test, I found one redirect that pointed to a slightly misspelled slug. I corrected it in the plugin, updated my CSV, and retested. Thorough testing at this stage prevents broken links from reaching real visitors.
Step 6: Monitor 404 Logs and Catch Stray URLs
Even with a careful CSV, some old URLs will slip through. The Redirection plugin automatically logs every 404 error that occurs on my site. I go to Tools → Redirection → 404 Logs and look for entries that clearly belong to the old platform’s structure, such as URLs containing date folders or old page prefixes like /p/. For each stray URL, I add a manual redirect directly in the plugin by clicking “Add Redirect,” or I append the entry to my CSV and re‑import; the plugin skips duplicates. I check the 404 log daily for the first week after migration, then weekly for the first month. After that, a monthly check is sufficient.
On my site, a few old tag archive pages appeared in the 404 log because they had not been included in the original CSV. I added redirects for those within days. This monitoring phase ensures that no old link remains broken for long.
Step 7: Handling Special Cases Like Mobile URLs, Old Page Slugs, and Trailing Slashes
Not all old URLs follow the standard format. Blogger creates duplicate mobile versions with a query parameter ?m=1 appended to every post URL. I must redirect these to the clean new address. A single regex rule in the Redirection plugin handles them: I set the source to /(.*)\?m=1, the target to /$1/, and check the “Regex” option. This strips the parameter and sends the visitor to the correct page.
Old page slugs on Blogger often use the prefix /p/, such as /p/about.html. I map these directly to the new page slug, like /about/. Trailing slashes must be consistent; if my new site appends a trailing slash to all URLs, my target in the CSV must also end with a slash. Mismatched slashes can cause an extra redirect hop, which wastes crawl budget. I keep the canonical URL as the target. In my CSV, every target ended with a trailing slash to match WordPress’s default permalink structure.
Step 8: Redirecting Old Feeds, Tag Pages, and Other Archives
Old sites often have RSS feeds, tag pages, category archives, and author pages that were indexed and may have backlinks. These also need to be redirected. If I am moving from Blogger, the old feed URL might be /feeds/posts/default; I redirect it to my new WordPress feed at /feed/. For tag and category archives, if my new site uses the same taxonomy structure, I redirect the old archive URLs to the matching new ones. If the structure is different, I create individual redirects for the most important archive pages and redirect the rest to the main blog page. Author pages with a single author can redirect to the About page or the new author archive.
On my site, I had a few category labels in Blogger that became WordPress categories with slightly different slugs. I mapped each old label URL to the new category URL. I included these archive redirects in my CSV just like regular posts.
Step 9: Using Regex for Pattern‑Based Redirects With Caution
When many old URLs follow a predictable pattern, a single regex rule can replace dozens of individual lines in my CSV. For example, if all old post URLs follow the format /YYYY/MM/slug.html and the new slugs are identical, I can set the source to /\d{4}/\d{2}/(.*)\.html, the target to /$1/, and enable the Regex option. This method is powerful but must be used with great care. A mistake in the regex pattern can break entire sections of the site.
I test the rule on a staging copy of the site first, and only use it when I am absolutely certain that every old URL matches the pattern and the captured group maps cleanly to the new slug.
In my own migration, regex failed because many slugs had changed during the import, so I could not rely on a pattern that assumed identical slugs. The manual CSV was the only safe route. I reserve regex for cases where slugs are unchanged and the pattern is uniform for example, redirecting all old archive pages that follow a consistent date structure. Another safe use is adding a rule that redirects all requests from an old subdomain to the new domain, which I cover later.
Before trusting a regex rule, I test it inside the Redirection plugin’s “Add Redirect” screen by entering a few example old URLs and checking that the plugin previews the correct new URL. I also check the rule on a staging site to ensure it does not conflict with any existing permalink structure.
Step 10: Choosing the Correct Redirect Status Code
A 301 Moved Permanently status code tells search engines that the old URL has moved forever and all ranking signals should be transferred to the new URL. This is what I want for every URL in my migration map. A 302 Found status code is temporary and does not pass full SEO value; I avoid it unless I plan to bring the old URL back, which is almost never the case in a platform change. The Redirection plugin defaults to 301, so I do not need to change any settings. I simply ensure that every redirect I create uses the 301 status.
Step 11: Avoiding Redirect Chains and Loops
A redirect chain occurs when an old URL points to a new URL that itself redirects again to a third URL. This wastes crawl budget and slows down visitors. My CSV must target the final canonical URL directly, not an intermediate address. A redirect loop occurs when a URL redirects back to itself or creates a circular path, often caused by a misconfigured rule.
To check for chains and loops, I use the browser’s developer tools Network tab to see the sequence of redirects, or I run a command‑line tool like curl -I -L on the old URL. If I find a loop, I examine the redirect rules in the plugin and remove the conflicting entry.
Keeping the redirect structure clean ensures that both users and search engines reach the content in the fewest possible steps. This step is especially important after importing a CSV that might contain an accidental circular reference.
Step 12: Communicating the Change to Google via Search Console
After all redirects are active, I go to Google Search Console and submit my new site’s sitemap. This helps Google discover the new URLs quickly. In the Indexing → Pages report, I see old URLs labeled “Page with redirect.” This is expected; over time, Google indexes the new URLs and phases out the old ones. I use the URL Inspection tool on a few old URLs to confirm that Google sees the 301 redirect and that the canonical URL is correct.
If I kept the same domain name, I do not need to use the Change of Address tool; Google associates the old and new URLs through the redirects. A clean sitemap submission combined with working redirects is the most important step for setting up Google Search Console with accurate data from the first day of a new site.
I continue checking the Index Coverage report weekly for the first two months. I watch for any old URLs that suddenly move from “Page with redirect” to “Not Found (404),” which would indicate a broken redirect rule. If I see that, I investigate and fix it immediately. Over time, the number of old URLs in the index drops, and the new URLs take their place.
Step 13: Update Internal Links to Bypass Redirects
My imported content likely contains links that point to my own old URLs. When a visitor clicks such a link, they go through a redirect functional but slightly slower. Updating these internal links so they point directly to the new URLs eliminates that extra hop and conserves crawl budget. I use a search‑and‑replace tool to scan my database for the old domain or any old URL patterns and replace them with the new, correct URLs.
A plugin like Better Search Replace allows me to run a dry‑run first, showing exactly which rows will be changed, before executing the replacement. I target the old domain and replace it with the new one. I also replace any other old URL structures, such as the date‑based folder pattern, if they appear in content.
After running the replacement, I go to Settings → Permalinks and click “Save Changes” to flush any cached rewrite rules. I spot‑check several posts to confirm that the links now point directly to the right pages. This step makes my internal link structure clean and efficient.
Step 14: Handle HTTPS/HTTP and www Versus Non‑www
My new site should be configured to force all HTTP requests to redirect to HTTPS. Most hosting providers handle this automatically when SSL is enabled, but I verify by typing the HTTP version of my domain into a browser; I should be sent to the HTTPS version. I decide on a single canonical domain version, either with www or without, and ensure both the WordPress Address and Site Address in Settings → General use that same version.
Any requests to the alternate version should redirect to the canonical one. In my CSV, the target is always the canonical version. The old source URLs can be from any variant; the 301 sends the visitor to the correct canonical address, which is fine. This consistency strengthens the site’s technical foundation.
Step 15: Testing Redirects in Bulk With Command‑Line Tools
For sites with hundreds of old URLs, testing each one manually is impractical. The command‑line tool curl can verify many redirects quickly. The command curl -I -L https://www.yoursite.com/old‑path fetches only the headers and follows the redirect chain, showing each HTTP status code. The final line should show 200 OK. If any step returns a 404 or a 500 error, the redirect chain is broken. I can write a simple script to loop through a text file of old URLs, run the command, and report any that do not end in a 200 status.
For example, on a Linux or Mac terminal, I save my list of old URLs as urls.txt (one per line with the full domain) and run a short cycle. For each URL, I run curl -o /dev/null -s -w “%{http_code}\n” -L URL and check that the final output is 200. Any URL that returns something else gets flagged for manual review. This bulk testing method is optional but saves significant time when migrating a larger site.
Step 16 : Third‑Party Services and CDN Redirects
If my site uses a CDN or a caching service, its stored copies may serve old redirects or block my tests. I purge the CDN’s cache after importing the redirect map so that all requests hit my server directly and the new rules take effect immediately. Old social media posts on platforms like Facebook or X may have cached link previews that point to the old URLs.
These platforms eventually re‑scrape the link and see the redirect, but I can speed up the process by using each platform’s debugging tool to re‑scrape a few important URLs. Links in old email newsletters cannot be changed, but the redirects I have set up catch them automatically and send readers to the correct new pages.
Step 17: Redirects for Custom Post Types, Taxonomies, and Authors
If my old site used custom post types, such as a portfolio or testimonials, or had custom taxonomies, those URLs must also be included in my redirect file. When the old and new slugs are the same, I can often handle them with a simple pattern rule. When the structure has changed significantly, manual individual mapping is necessary.
The exact rule applies to category and tag archives; if the new site groups content differently, I may need to create separate redirects for the most important archives and redirect the rest to a general blog page. Author pages, if I have multiple contributors, each need their own redirect. For a single‑author site, one redirect from the old author URL to the new About page is enough.
Step 18: Handling Multilingual or Country‑Specific URLs
If a site had subdomains for different languages for example, fr.example.com each subdomain would be a separate property requiring its own redirect file. If the old site used subdirectories like /fr/ and the new site keeps the structure, the old URLs can be mapped to the new ones accordingly. If the new site does not maintain language‑specific sections, those old URLs could be redirected to the main language version of the content or to a language selector page.
I always use 301 redirects only when the content has truly moved; I avoid cross‑domain redirects that might confuse search engines about the site’s structure. In my own case, my site did not have any language subdomains or subdirectories, so this step was not needed, but I include it here for anyone whose site does.
Step 19: When to Remove Old Redirects
Redirects should stay in place as long as the old URL had backlinks or was indexed. After a year or two, some old URLs may show zero traffic and have no external links. I use the Redirection plugin’s logs to identify redirects that have not been hit at all during the last twelve months.
Removing these unused redirects keeps the plugin’s database clean and reduces server overhead. However, I never remove a redirect that is still receiving even occasional hits or that has an external backlink pointing to it. A broken backlink is a lost ranking opportunity. If I remove a redirect and later a request comes in, the plugin logs a 404, and I can re‑add it.
Step 20: Building a Redirect File for Any Platform
The manual CSV method I used for Blogger to WordPress works for any platform migration. Whether you are moving from a website builder, a different content management system, or a custom‑coded site, the steps are identical. Crawl the old site while it is still live, using a sitemap, a crawler tool, or the export function of the old platform, to get every URL.
Identify the new URLs on the new site. Build the CSV, import it, and follow the testing and monitoring process. The only variation is how you extract the old URLs, but the core principle remains the intact. Building a thorough file before launching the new site is the foundation of a complete redirect map that preserves every existing link and search ranking.
Troubleshooting Common CSV Import Errors
When the import fails, the cause is almost always one of a few common issues. If the plugin reports that zero redirects were imported, I open the CSV in a plain text editor and check that the delimiter is a comma, not a semicolon, and that the header row reads exactly source,target with no extra spaces. If I see an “Invalid group” error, the Redirections group does not exist yet; I create it under Redirection → Groups and try the import again.
If redirects appear to be imported but do not work, I verify that the source path in the CSV exactly matches the old URL path, including trailing slashes and percent‑encoded characters, and I clear any caching layers that might be serving stale rules. Special characters that appear garbled after import usually mean the file was not saved as UTF‑8 without BOM; I re‑save it with the correct encoding.
Another common issue is that the plugin may time out on very large CSV files. For sites with thousands of URLs, I split the CSV into smaller files of 500 rows each and import them sequentially. The plugin skips duplicates if I include the header in each file. I also avoid importing into a group that already has a large number of existing redirects, as that can slow down the processing. These simple fixes resolve nearly every import problem.
Maintaining Your Redirect File for the Long Haul
The redirect file is not a one‑time task. I keep a master copy of my CSV stored on my computer and backed up in cloud storage. Whenever I delete or move a post on the new site, I add a new redirect through the plugin’s interface and then manually update my master CSV so it remains the single source of truth. Every few months, I review the plugin’s 404 log and the list of existing redirects.
I remove any redirects that have had zero hits for over a year, as described earlier. This regular maintenance ensures the redirect structure stays clean and that no broken links accumulate over time the discipline of a regular maintenance routine is the principle behind a simple weekly SEO routine that keeps a blog healthy.
What a Complete Redirect File Does for Your Site
A fully executed redirect file preserves every existing backlink and the SEO authority those links carry. It prevents the 404 errors that frustrate visitors and waste the crawl budget that search engines allocate to your site. It tells search engines exactly where each piece of content has moved, transferring the rankings that were earned over months or years.
It keeps old social media posts, bookmarks, and email links functioning. It eliminates the need for anyone to search again for content they expected to reach. For my site, with 91 pages redirected, the result was a transition with no measurable traffic loss and a growing presence in search results. The redirect file was the technical foundation that made everything else possible.
The Complete Redirect Migration Checklist
Before I launch a migration, I confirm every item on this list:
1. Old URLs extracted from a backup file, sitemap, or crawl and saved in a text file.
2. Matching new URLs verified manually side‑by‑side.
3. CSV built with the correct header, relative paths, and UTF‑8 without BOM encoding.
4. CSV imported into the Redirection plugin into the Redirections group.
5. At least ten random old URLs tested in an incognito browser; all return a 301 status.
6. 404 log monitored daily for the first week; stray URLs redirected immediately.
7. Internal links updated via search‑and‑replace to point directly to new URLs.
8. New sitemap submitted in Google Search Console; redirect status accepted as expected.
9. Master CSV backed up in two separate locations.
I print this checklist or keep it open during a migration. Marking each item complete ensures that no step is overlooked. A systematic approach is what separates a smooth platform change from one that creates months of recovery work this kind of step‑by‑step preparation is the approach I use for building a self‑discipline system that survives the chaos of daily life.
Important Context for Applying This Method
The method I have described is based on my direct experience managing my own site during a platform migration. I share it because it worked for me, not because I promise identical results for every situation. Server environments, plugin versions, and platform configurations vary. Every website is different. All actions described editing files, running imports, modifying server‑level redirects carry their own risk. I always take a complete backup before starting any migration work. Decisions about a website remain entirely the responsibility of the person who owns it.
This guide is a tool for awareness and preparation, not a substitute for professional judgment. When circumstances are complex or uncertain, consulting a qualified developer is the wisest course.
The Deeper Value of Getting Redirects Right
Beyond the technical details, building a correct redirect file is an act of respect for the audience that has already found my work. Every old link that still works is a promise kept to someone who bookmarked an article, shared it with a friend, or cited it on their own site.
When those links continue to function seamlessly after a migration, trust is maintained. When they break, trust is broken. The hours I spent matching 91 old URLs to new ones were an investment in the reliability of my site. This reliability compounds over time, turning simple articles into a genuine digital resource that grows in value year after year the technical work of redirects is ultimately about honoring the connections that were already made and ensuring they remain intact.
Practical First Steps for Anyone Facing a Migration
If I were planning a platform change today, the most important action I would take is to extract every URL from my current site while it is still live. I would not wait until after the migration. I would export the backup file, download the sitemap, run a crawler, and save that list of URLs in a safe place. That list is my insurance policy.
Once I have it, I would begin matching the old URLs to the new ones, even if the new site is not yet public. Starting early transforms a rushed, stressful task into a manageable, systematic one. The CSV method I have described will work, regardless of which platforms I am moving between. The tools are free. The process is repeatable. The only variable is the decision to begin before the old site disappears.
Disclaimer:
This guide reflects my personal experience migrating a small website from Blogger to a self‑hosted WordPress platform. The steps I followed worked for my 91 pages, but every website has unique configurations, server environments, and content structures. The tools and techniques mentioned are those I personally used and found reliable; I do not endorse or guarantee any third‑party product or service. Implementing redirects incorrectly can cause temporary or permanent loss of traffic, and I accept no responsibility for any outcomes resulting from the application of this method. Always test on a staging site first, take a complete backup before making changes, and consult a qualified professional if you are uncertain. The decisions you make for your own site are yours alone.