Leaving WordPress.com Without Losing the Permalinks

A blog moved off WordPress.com on a Saturday. The import reported success, the library filled up, and by Sunday every post sat on the new server with the theme the owner had wanted for two years. The content had moved. Nothing looked broken.

Six weeks later the search console showed the damage. Posts were still indexed against /2021/04/12/what-a-cache-purge-does-not-fix/ while the new site answered on /what-a-cache-purge-does-not-fix/, and each old address returned a 404 to browsers and crawlers alike. Traffic did not collapse in a day. It leaked, a post at a time.

Nothing in the export was wrong. It did what the label says and carried the content. The addresses were a separate object, and nobody copied them. The migration is a URL preservation exercise that happens to involve posts, and the order of operations is the whole technique.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the case for staying on the free plan is made below, and so is the case for not buying a plan at all.

What the export carries, and what it is not

The export is a WXR file, and its contents are narrower than the name suggests: posts, pages, comments, categories, tags, and for every media item an instruction about where the file lives. Not the file. WordPress.com's export documentation says so in one sentence, and that sentence sets the order of the migration, because the new site copies each image from the old one during the import.

That dependency kills the common sequence of export, cancel, import. Cancel first and the importer finds nothing at the far end of its instructions; it reports a partial success, and the gaps sit in the posts that carried the most images.

The file omits the site's shape as well: permalink structure, archive URLs, front page setting, menu locations. It gives post_name and post_date per post, enough to rebuild a date-based address by hand, which is exactly the work a redirect map does once from data instead of later from memory.

It omits the theme too, along with the customisations and the plugins. A site that looked like something will not look like it on the other side, and that is a day of work rather than an hour.

Inventory the addresses before anything moves

Twenty minutes on the export settings first: set the site to public visibility, or the importer cannot fetch the images, and delete drafts and spam so the import does not rebuild an inbox that took a year to clear.

Then write down every address the site answers on. Not the posts: the addresses. Four hundred posts become closer to two thousand URLs once archives are counted, and each one is a thing somebody linked to.

• Every post and page with its full path, from the sitemap, which lists the path WordPress.com actually serves rather than the one the slug implies.
• Category and tag archives and their pagination, which rank more often than expected where the archive is the best page on the site.
• Author archives, date archives, the feed, and any search URLs that were ever shared.
• Attachment pages, one per media item, which do get indexed.
• Both hosts. The custom domain and the .wordpress.com address collect links independently.

The sitemap is the site's claim about what exists; the search console's page report is what the index believes. Where they disagree, the index is right about what matters.

Then choose the structure on the new host, before the import, because the map is written against it. Keeping WordPress.com's date-based /year/month/day/slug/ leaves every old address correct and shrinks the map to nothing, at the price of a URL that looks dated in five years. /slug/ is tidier and costs a redirect per post. That trade is fine while the map is complete; a partial map is worse than the date-based structure, because half the archive ranks and the other half 404s.

The redirect map is written before the switch

The old URLs exist only while the old server answers for them. Once the nameservers move, the only record of what sat at a path is the list somebody wrote down. Reconstructing it afterwards means guessing from search results and the Wayback Machine, both incomplete where the traffic was.

The map is a file with two columns and a status: old path, new path, 301. Generate it from the export, check it against the inventory, and commit it beside the server configuration so it survives the person who built it.

Three rules. One hop, because a chain loses link value and breaks at the second hop when a plugin changes its rules. One host at a time, because the .wordpress.com address and the custom domain need separate rules. And cover the awkward URLs, where most of the value is: the feed, the paginated archives, the category paths, the attachment pages.

Implement it in the server configuration, not only in a redirect plugin. A plugin gets deactivated during a debugging session and its rules go with it. Plugins suit rules that change weekly; the migration map does not.

Then test it. A short script that requests every old path against the staging copy and asserts a single 301 to a 200 gives the only yes or no in the job.

The domain and DNS during the cutover

The domain has to survive, and it is the least surprising part if the records are copied first. Dump the zone: A, AAAA, CNAME, MX, TXT, plus the verification records a mail provider added. Keep a text copy as well as a screenshot; screenshots do not survive a control panel redesign. If the domain is registered at WordPress.com, edit the zone there or move the nameservers; either way every record must exist at the destination before the change.

Email breaks quietly. WordPress.com's forwarding stops with the plan, and a forwarding rule that disappears takes password resets with it. Recreate the mailboxes, test each one, then touch the site records.

The order that works:

1. Lower the TTL on the A and CNAME records a day ahead. A day is enough, and a five-minute TTL left in place for a year is its own problem.
2. Build the new site on the host's temporary URL, with the certificate and the permalink structure already set.
3. Import while the WordPress.com site is still public and still paid for, then compare media counts on both sides.
4. Fix permalinks, map and internal links on the staging copy, and test them there.
5. Change the A record and the www CNAME, adding any verification record the host requires beforehand.
6. Leave the WordPress.com plan running for a month. It is the rollback target and the only thing that can still answer on the old host.

The certificate is not a detail. If the new host issues one on first request and the nameservers have already moved, the first visitor sees a warning on a domain that worked an hour earlier.

What the export leaves behind

Four things do not travel, and each has a workaround. None is difficult. All are forgotten until the site is live.

The generated image sizes. The export carries the original file and the attachment metadata, not the crops and thumbnails the theme asked for. The new site regenerates them, which is normal and occasionally wrong: a theme that crops to a fixed ratio produces different files, and a template that hardcoded a size no longer generated shows a broken image. Regenerate before the cutover, then compare the pages that use featured images.

The theme customisations. Menus, widgets, the logo, colours, fonts, custom CSS and editor changes live in the database, and the export is not a database dump. Rebuilding on the staging copy is the difference between a weekend and a fortnight. Where the old site leaned on custom CSS, copy the stylesheet instead of re-clicking the customiser.

The subscribers. Followers, email subscribers and everyone who signed up through the Reader are a WordPress.com asset rather than content, and the export excludes them. The free Jetpack plugin and its support documentation cover the subscriber migration route, which works by connecting the new site to WordPress.com, the very connection some people are leaving to avoid. The alternative is exporting the list while the plan is still active. Either way, do it before cancelling: the list leaves with the plan.

Whatever a plugin stored. The plugin list on WordPress.com is short, but anything a form, a poll, a shop or a statistics package wrote into its own tables stays behind, and so do the options. That is where search-and-replace goes wrong: a naive replacement across serialised data changes a string's declared length, and WordPress discards the option without an error. WP-CLI's search-replace command handles serialisation; a text editor does not.

Also left behind: user accounts and passwords, since posts arrive assigned to author names; post IDs, which break any shortcode referencing them; scheduled posts; and revisions.

The free subdomain cannot be redirected the way people expect

One detail decides whether this migration is a weekend or a permanent loss of rankings, and it is absent from most guides.

On the free plan the address is yoursite.wordpress.com, a domain that is not yours to point anywhere. WordPress.com does sell a way out: a site redirect sends the whole .wordpress.com address, permalinks included, to another site. It is a paid upgrade, and the limits matter more than the feature. It points only at an http destination, leaving the new host to finish the upgrade to HTTPS. Inner pages resolve only if the destination uses WordPress.com's date-based structure, so /slug/ breaks every post except the home page. It cannot target a single file, only a domain or a directory path. And it cannot be paused; deleting it is the only way to stop it.

The documentation also rules it out for sites with plugins installed or hosting features active, which describes any site that has grown enough to have a redirect problem.

It lasts only while the plan is paid. Cancel and the redirect leaves with the address it was redirecting. A .wordpress.com URL is rented, not owned, and the day the subscription lapses every inbound link written in the last five years stops resolving.

Which gives the rule the rest of this sits under. WordPress.com's plan and domain options are worth reading before the decision rather than after, because the order matters: attach a custom domain and make it primary while the site is small, then migrate when there is a reason. Staying on the free plan is the free answer until something links to the subdomain. The domain itself can be transferred or pointed elsewhere. The subdomain goes nowhere, and once it holds traffic and links, keeping them alive means paying for the address they point at.

When staying is right, and when paying is the wrong answer

The free plan is genuinely enough for a site with no custom domain, no revenue and no archive worth preserving. A few hundred readers and forty posts do not justify the weekend, and a botched migration costs more attention than staying ever will.

Paying WordPress.com is the wrong answer in the case most readers are in: the site needs plugins, a theme it controls and access to its database, which is the reason for leaving. A year of the top tier to solve a redirect problem, on a site that is moving anyway, is a detour with an invoice attached. Buy the domain, pay a host, and put the money into the thing that will still be true in two years.

WordPress.com's plan comparison is the right first step when the answer sits in the middle: the site is staying, the maintenance is not wanted, and the address needs to be a domain. Check the current price, they change it, and check which features the plan includes, because custom permalinks and plugin access decide everything else here.

The decision rule, in the order the dependencies run. If the site is on a .wordpress.com address and anything links to it, deal with the address first: a domain, primary, indexed. Then export, inventory, write the map, move. If the address is already indexed and there is no domain, the redirect problem has no free solution, so the choice narrows to paying for the address or rebuilding the links by hand, and it is better made deliberately than discovered in a search console graph three months later.