Moving from WordPress to another platform: what transfers, what gets lost.

When moving from WordPress to another platform, content, images and addresses can be transferred; what gets lost is mostly the work plugins quietly did: the sitemap, search titles, structured data, redirects, forms. For the migration to preserve search visibility, every old WordPress address needs either an equivalent on the new site or a deliberate 404/410 decision.

The decision to leave WordPress usually starts with a complaint: the site is slow, plugin updates are nerve-racking, the design no longer reflects the company. The new platform might be another content management system, a static site generator or a custom-built site. Whichever it is, the migration consists of two separate jobs: moving the content and rebuilding the work WordPress did out of sight. When the second is skipped, the site looks new and fast, but its place in search quietly erodes. That is why the whole migration runs on a migration checklist, and within site redesign and migration work, moving off WordPress is a separate line item.

What transfers easily from WordPress?

WordPress’s own export tool (Tools › Export) dumps the content into an XML file called WXR. According to the WordPress documentation, this file contains posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users. Text, titles, dates and category information can be imported into the new system this way. Media files such as images and PDFs are copied separately; if their addresses will change on the new site, they go into the map too.

What gets lost when moving off WordPress?

What gets lost is the work done not by WordPress itself but by plugins and the theme. If a plugin does a job, that job leaves with the plugin:

• Search titles and descriptions. The titles and descriptions you entered page by page in an SEO plugin are lost unless they are imported into a matching field in the new system, and the pages go live with default titles.
• The sitemap. The plugin-generated sitemap disappears; the new system has to generate its own sitemap, and it has to be resubmitted to Search Console.
• Structured data. Schemas such as breadcrumbs, organization details and article details were output by the plugin; they have to be rewritten in the new system.
• Redirects. Rules added to a redirect plugin over the years vanish overnight unless they are exported. They are the record of earlier migrations; add them to the new map.
• Forms, memberships, comments, e-commerce. Each one either finds an equivalent in the new system or is deliberately shut down.
• Editing habits. Who updates the content, and from which screen, may change; this is an organizational decision, not a technical one, and it should be made before the migration.

How are WordPress addresses handled on the new site?

WordPress’s URL structure is distinctive, and it is the part of the migration that creates the most work. According to the WordPress documentation, the default permalink on installation is “plain”: an address in the form ?p=123 that carries the post’s database ID. Many sites replace this with a structure that includes the post name, year or month. Category and tag archives have their own addresses too; their default prefixes are category and tag, and according to the documentation they can be changed but not removed from the address entirely. On top of these come pagination, author and date archives, feeds and media addresses.

Each pattern becomes a separate rule in the map. The lines below show the patterns of a typical WordPress site and possible decisions; the addresses and decisions are examples, and your site’s decisions depend on its own content.

1. /?p=123 → /yazilar/fuar-notlari/ · 301 (ID → name, line by line)
2. /2019/05/fuar-notlari/ → /yazilar/fuar-notlari/ · 301 (pattern rule)
3. /category/haberler/ → /yazilar/ · 301 (if an equivalent list exists)
4. /tag/fuar/ → (no equivalent) · 410
5. /2019/05/ → (date archive · no equivalent) · 410

Two rules matter. First, do not send category or tag pages wholesale to the homepage; if there is no equivalent list, 404 or 410 is the more honest answer (404 error guide). Second, write the old address of every exported post into the map as a line of its own. How to set up redirects is in the 301 redirect guide.

Can the old WordPress site stay live?

It should not. If, after the new site launches, the old installation remains accessible at another address — a subdomain or a temporary address — two copies of the same content are live at two different addresses, and the search engine decides on its own which one to show. The old addresses should be redirected to the new ones, and the old installation should be kept as an archive behind a password, somewhere only the team can access. The same rule applies to the new site’s staging environment: it should not be public before launch, and on launch day it should not leave behind settings that block search engines.

What should you choose instead of WordPress?

There is no single right answer. For a site where many people update content often, or that carries memberships or a store, another content management system makes sense. For a corporate site whose content changes rarely and where speed and a small attack surface are priorities, a static site often means fewer moving parts. The two paths are compared in the static site or content management system guide. If a static site is chosen, the next question is whether to use an off-the-shelf generator or one you write yourself; you can find this in our measured comparison Astro or your own generator. Among our projects, the Mikro Yazılım Destek site was built with Astro.

What changes when you do the plugin’s job yourself?

This site does not use WordPress; a single generator we wrote ourselves produces its pages, structured data, sitemap, RSS feed, robots.txt and llms.txt files. In other words, every job left to plugins in WordPress lives in our own code here. We have experienced both sides of this.

One day Search Console’s breadcrumb report showed an error for an unnamed item: one step in the schema was missing its name. Had we used a plugin, we would have fixed it by waiting for a plugin update; here we added a rule to the generator, and since then any breadcrumb with an unnamed item is caught at build time and stops the build. In the same export, the profile page report flagged the page’s modification date, which was output as a day only without a time, as an invalid datetime; the fix was a datetime with a time zone (September 23, 2026).

The lesson cuts both ways. When you do the plugin’s job yourself, you also make the mistakes yourself; reading Search Console is a job that has to continue after the migration. But the fix is also in your hands, and an error caught once can be locked down so that it can never be produced again. When leaving WordPress, the question to ask is not only “what gets lost when the plugins go” but just as much “who will check their replacements, and how.”

Removing a plugin does not remove the work it did; it only changes who does it.

In what order should you proceed when moving off WordPress?

• Pull the old site’s address list: the WordPress sitemap, Search Console and a crawl. Export the redirect plugin’s rules as well.
• List the plugins and write down what each one does: where will this job be done in the new system?
• Export the content; verify page by page that the SEO titles and descriptions have been imported into a field in the new system.
• Set up the new URL structure and write down a decision for every old address: 301 or 404/410.
• On launch day, test the map live, line by line; submit the sitemap.
• In the weeks after the migration, monitor Search Console; keep the old WordPress installation as an archive for a while, and do not leave it public.

Moving off WordPress brings to light the invisible work a site has accumulated over the years. Writing this list before the migration always takes less time than searching for the cause of the loss after it.

If you don’t want to lose traffic while relaunching your site, website redesign and migration inventories the old addresses, builds a chain-free 301 map and monitors the site for 90 days after the move.