Move from WordPress to a flat-file PHP site without losing the content or URLs you already earned.

Build the new site beside the live one. Map every URL. Test every public page. Keep a working rollback copy until the move is proven.

The export is only the starting point. The real job is carrying over the working parts that surround the content. Images and downloads still need to load. Forms still need to work. Search Console still needs to know the site belongs to you.

Keep your WordPress URLs when you can

A platform change does not require a URL change. If an article already lives at /guides/example/, the new flat-file site can keep that address.

Keeping the same URLs removes a large part of the risk. Existing links still work. Bookmarks still work. Search systems can find the page where they found it before.

When a URL must change, give the old address one permanent server redirect to the closest matching new page. Do not send every old page to the homepage. Google calls for an old-to-new URL map and direct permanent redirects when addresses change.

The eight-step WordPress to flat-file migration plan

  1. Make a rollback copy before touching the live site. Save the WordPress files and a database export. Download the WordPress eXtended RSS file from Tools > Export. Keep copies of the current DNS records and Apache rules too.
  2. List what the working site actually depends on. Record every public URL. Save the uploads and downloads. List each form and redirect. Note what every plugin does so the new site can replace the job instead of merely removing the plugin.
  3. Design the JSON record before converting the content. Decide which fields every article needs. A useful record usually carries the title and slug. It also needs the body, excerpt, dates, author, categories, relationships and page description.
  4. Convert the content and clean what WordPress leaves behind. Parse the export into the new JSON shape. Remove dead shortcodes and plugin markup. Copy media into stable folders. Fix image links before the new site is tested.
  5. Map every old URL to its final answer. Keep the current address wherever possible. When an address changes, record the exact destination and create one direct permanent redirect. Return a real not-found response when no useful replacement exists.
  6. Test the new site away from live traffic. Crawl every route. Check titles and self-canonicals. Open the public JSON records and sitemap. Test forms and downloads. Read representative pages on desktop and mobile instead of approving the move from source files alone.
  7. Cut over once the new copy passes. Upload the final files and server rules. Change DNS only if hosting changes. Turn on the redirect map when URLs change. Publish the current sitemap and keep the ownership verification files in place.
  8. Prove the move before retiring WordPress. Crawl the live site again. Follow every redirect to its final page. Watch server errors and Search Console. Test the primary forms and downloads. Keep the rollback copy until real traffic has used the new site without surprises.

What the WordPress export gives you

WordPress creates an XML file in its WordPress eXtended RSS format. Its current documentation says the file can include posts and pages. It can also include custom post types, comments and custom fields. Categories, tags, custom taxonomies and users may be included too.

That makes it a useful content source. It does not replace the separate file copy and database backup you need for rollback.

The export also reflects years of WordPress decisions. Expect shortcodes that no longer mean anything. Expect plugin HTML and old embeds. Expect image addresses tied to the uploads folder.

The conversion script gets the records into JSON. The cleanup pass makes those records worth publishing.

Replace each WordPress plugin job on purpose

A plugin list is really a list of jobs the current site performs.

  • An SEO plugin may write titles, canonicals and structured data.
  • A form plugin may handle delivery and spam checks.
  • A redirect plugin may protect addresses that still receive traffic.
  • A cache plugin may hide how much work WordPress performs for each request.
  • A security plugin may block attacks against the login and database-backed code.

A flat-file rebuild may solve those jobs in very different ways. That is fine. The mistake is assuming the jobs disappeared because the plugins did.

Use the same domain without changing every address

Moving to flat-file PHP is often a content management system change on the same domain. In that case the best result is boring: the page addresses stay where they are and the system behind them changes.

If the domain or visible URLs change, the migration becomes a search move too. Google recommends mapping old addresses to new ones. It also recommends server-side permanent redirects and an updated sitemap.

If only the hosting changes, the public URLs can stay the same. The launch work then centers on DNS and crawl access. Ownership verification and server monitoring still matter.

A rollback copy is part of the launch

A rollback is not a folder someone hopes is complete.

It is a tested copy of the old site with a clear way back.

On the PHP and JSON sites behind this guide, the live site is backed up before a production file changes. The edited file is validated before upload. The live copy is then checked from the browser and from the server.

That system exists because a clean local file does not prove a clean public page.

What you gain from a flat-file PHP site

You gain content records you can open and read without a database. You gain templates whose output can be traced without a plugin stack. You gain a site that can expose useful JSON alongside the public page.

You also take direct responsibility for the system. There is no WordPress dashboard waiting to update a plugin or correct a form setting. Backups and validation become your job.

That trade makes sense for one owner who works directly with files and wants full control. It makes less sense for a large editorial team that needs roles, approvals and a visual editing screen.

The point is not to escape WordPress

WordPress is useful when its editing screen and plugin system solve problems you actually have.

A flat-file PHP site is useful when the site needs fewer moving parts and clearer content records. It also works well when one owner wants to understand every file being published.

If that sounds like your site, read the case for flat-file publishing. Then use the PHP and JSON setup guide to see what the new system needs before you move anything.

Current migration references