# How to Export WordPress Content Without Plugins

> By Lawrence Arya, Founder, WPBuildAI. Published 2026-08-17. 10 min read. Guides.
> Source: https://wpbuildai.com/blog/how-to-export-wordpress-content-without-plugins/
> Language: en

The data was always yours through the front door and the built-ins; the plugins were packaging.

**TL;DR.** WordPress exports without plugins through four built-in routes: the Tools Export screen (WXR with posts, pages, drafts, taxonomies), the core REST API (public content as rendered JSON, no login), WP-CLI (database-level completeness with server access), and a front-end crawl (the rendered site, working even locked out). For migrations off WordPress, compose them crawl-first, the WPBuildAI method: the rendered site as inventory and contract, native exports supplementing drafts and private content, media pulled from the recorded URL list.

You can export WordPress content without installing a single plugin through four built-in routes: the native export screen that ships with every install, the REST API that serves your content as JSON over plain HTTP, WP-CLI if you have server access, and, for the cases where wp-admin itself is out of reach, a front-end crawl of the live site. Which route fits depends on what you have access to and what the export is for, and the honest hierarchy for a migration is the one WPBuildAI runs: crawl the rendered site as the source of truth, because it captures what plugins and themes actually output, and use the native exports as supplements for drafts and private content the crawl cannot see. Each route, what it carries and drops, and the workflow for the common cases.

## Route one: the built-in export screen

Every WordPress install ships an exporter at Tools, then Export, no plugin required: it produces a WXR file, WordPress's XML flavor, containing posts, pages, comments, categories, tags, custom fields, and menus, with options to filter by content type, author, or date range. Its virtues are availability and completeness of the editorial layer, including drafts and pending posts nothing public ever showed, and [the official documentation](https://wordpress.org/documentation/article/tools-export-screen/) is candid about the shape: it is content, not a site backup, and not a copy of what visitors see.

The gaps define when it is not enough. The WXR file references media by URL rather than bundling files, so images need a separate copy step. It carries the raw editor content, meaning shortcodes unexpanded and page-builder markup as stored blobs, not the rendered output your visitors and Google actually consumed. Plugin-managed data, SEO titles and descriptions above all, lives in tables the exporter does not touch. And it knows nothing about your URL structure beyond permalinks, redirects, or anything a theme renders. For moving between two WordPress installs it is the designed tool; for leaving WordPress, it is one input among several, never the inventory.

## Route two: the REST API, JSON over plain HTTP

Since version 4.7, every standard WordPress site publishes its content as machine-readable JSON at predictable endpoints, wp-json/wp/v2/posts, pages, media, categories, no authentication needed for public content and no plugin involved: [the REST API](https://developer.wordpress.org/rest-api/) is core WordPress. A few paginated requests pull every public post with its title, slug, rendered content, excerpt, dates, and taxonomy relationships, and the rendered flavor is the quiet advantage over WXR, because the API serves content with shortcodes expanded the way the front end does, closer to the truth visitors saw.

Practical notes from running this weekly: paginate with the per_page and page parameters and read the total-pages response header rather than guessing; pull the media endpoint separately to get file URLs for downloading; expect custom post types to appear only if the site registered them with REST support; and know that some security configurations disable or restrict the API, in which case the crawl route below does the same job from one step further out. For anyone comfortable with a script or even a browser, this is the fastest plugin-free route to structured content, and it works from anywhere, no login required for the public layer.

## Route three: WP-CLI, when you have the server

With SSH access to the hosting box, [WP-CLI](https://wp-cli.org/) does everything the admin screens do and more, from the command line, no plugin installed: wp export produces the same WXR with more filtering control, wp db export captures the full database for archival, and targeted queries pull exactly the tables a specialist needs, the postmeta rows where plugin-managed SEO data hides being the classic example. This is the professional's supplement route: not because the WXR is better from the command line, but because the database-level access recovers the plugin-managed layers the standard exporter drops, which for a ranking site is precisely the metadata worth carrying.

Its limits are access and audience: most site owners on managed hosting never see a shell, and raw database exports answer questions only for people prepared to read them. When we run migrations at WPBuildAI, this layer is the supplement to the crawl, used to reconcile anything the rendered site could not show, never the primary inventory.

## Route four: the front-end crawl, the export that always works

The fourth route ignores wp-admin entirely: crawl the live site from the outside and record what it serves, every URL, the rendered content, titles and meta descriptions as actually output, images as actually embedded, internal links as actually placed. This is the only route that captures the site as the world and the search engines experienced it, plugin output and theme rendering included, and the only one that works with no access at all, which is why it rescues the locked-out cases, the disappeared-developer sites, the hosting disputes, even [hacked sites whose admin is gone](/blog/common-wordpress-security-problems-and-how-to-avoid-them/) but whose public pages still serve. It is also the route that produces a migration-grade inventory, which is why [the crawl-first method](/blog/what-is-a-crawl-first-migration/) builds on it: for a platform move, what the site rendered is the contract, and the editor-side exports are supplements.

Its honest gaps mirror the others' strengths: no drafts, no unpublished content, no private data, nothing behind logins, which is exactly the material routes one and three carry. The complete export for a serious migration is therefore a composition: crawl for the rendered truth, WXR or CLI export for the private layer, media copied by URL list from either.

| Route | Access needed | Carries | Drops | Verdict |
| --- | --- | --- | --- | --- |
| Front-end crawl | None, public site only | Rendered pages, URLs, metadata, images as served | Drafts, private content | Source of truth for migrations, the WPBuildAI primary |
| Export screen (WXR) | wp-admin | Posts, pages, drafts, taxonomies, menus | Media files, rendered output, plugin data | Right for WP-to-WP moves |
| REST API | None for public content | Structured JSON, shortcodes rendered | Plugin tables, some custom types | Fastest structured pull |
| WP-CLI | Server shell | Everything, database included | Nothing, but raw | The specialist's supplement |

## The media layer, the step every route defers

Every route above defers the same job: the media files themselves. WXR references them, the REST media endpoint lists them, the crawl records their URLs, and none of the three hands you the files, so a complete export always ends with a download pass over the media URL list. The mechanics are a loop of HTTP fetches, any download tool takes the list, and the two details that separate clean from messy: preserve the path structure, because post content references images at their full paths and a flattened folder breaks every embed you later restore; and capture the size variants deliberately, since WordPress generates several files per upload and the rendered pages may reference any of them, which is one more argument for deriving the list from the crawl, the record of what pages actually embed, rather than from the uploads directory, the record of everything ever uploaded including years of orphans. On a migration, that difference is real money: rebuilding against the crawl's media list carries what the site uses and quietly retires the dead weight.

## The workflows for the three common cases

Moving to another WordPress install: export screen WXR, import on the other side, then copy the uploads folder or let the importer fetch media, and reconcile plugin-managed SEO fields by hand or CLI, the one layer the designed path still drops. Leaving WordPress for a modern platform: crawl first for the full rendered inventory, REST API or WXR for drafts and anything private, media downloaded from the crawl's URL list, and the [migration checklist](/blog/website-migration-checklist-before-you-switch-platforms/) governs what happens to every recorded URL, because the export is only half the job, the mapping is the other. Archiving or escaping a bad situation: whatever route access allows, crawl if you have nothing, CLI database dump if you have everything, and both if the situation is genuinely contested, since redundant copies cost minutes and disputes cost months.

Across all three, the plugin-free constraint turns out to be no constraint at all: the built-in routes cover every case the export plugins cover, with the plugins mostly adding convenience packaging around the same WXR and the same database reads, at the price of one more thing installed on a site you are trying to leave cleanly.

## Key takeaways: exporting WordPress content without plugins

Four built-in routes cover everything: the export screen's WXR for the editorial layer including drafts, the REST API for structured JSON of all public content with shortcodes rendered, WP-CLI for database-level completeness when you have the server, and the front-end crawl for the rendered truth that works with no access at all. For migrations off WordPress, compose them in the crawl-first order, the rendered site as the inventory and contract, editor-side exports as the private-layer supplement, media pulled from the recorded URL list, which is exactly how WPBuildAI runs every rescue and rebuild. The plugins you skipped were packaging; the data was always yours through the front door and the built-ins.

## Quick answers

### How do I export WordPress content without plugins?

Four built-in routes: the export screen at Tools then Export produces a WXR file of posts, pages, drafts, and taxonomies; the core REST API serves all public content as JSON at wp-json endpoints with no login; WP-CLI exports content or the whole database from the command line if you have server access; and a front-end crawl records the rendered site, URLs, metadata, images, exactly as visitors and Google saw it, with no access at all. For a migration, compose them crawl-first, the method WPBuildAI runs: rendered site as the inventory, native exports for drafts and private content.

### What does the built-in WordPress export actually include?

The WXR file carries the editorial layer: posts, pages, comments, categories, tags, custom fields, navigation menus, and crucially drafts and pending content nothing public ever showed, filterable by type, author, and date. What it drops defines its limits: media files are referenced by URL but not bundled, shortcodes and builder markup stay unexpanded rather than rendered, plugin-managed data like SEO titles stays in untouched tables, and URL structure beyond permalinks is absent. Designed for WordPress-to-WordPress moves, supplementary for anything else.

### Can I get my content out if I'm locked out of wp-admin?

Yes, from the public side: the REST API serves structured JSON of every public post and page without authentication on standard sites, and where the API is restricted, a front-end crawl records everything the site serves, content, metadata, images, URLs, requiring nothing but the site being online. This is the standard rescue for disappeared developers, hosting disputes, and hacked admin panels, and it is the foundation of WPBuildAI's locked-out migrations: the rendered site is the one export no one can withhold from you.

### Is the REST API export better than the XML export?

Different layers of truth: the REST API serves content with shortcodes rendered, closer to what visitors saw, in structured JSON that scripts consume easily, but only the public layer; the WXR export carries drafts, private posts, and menus the API never shows, in the raw editor format with shortcodes unexpanded. For feeding a rebuild, rendered JSON usually serves better; for completeness of the editorial archive, WXR wins; for a real migration you take both, plus a crawl, because each route drops what another carries.

### When should you not rely on a plugin-free export?

Rarely for the export itself, since the built-ins and the front door cover the data: the plugins mostly repackage the same WXR and database reads with convenience features, scheduled bundles, zipped media, one-click formats. The honest cases for one: a non-technical owner needing scheduled full backups without a shell, or a bundled media-plus-content archive in one click on a site staying on WordPress. On a site you are leaving, adding software to extract data the built-ins already serve is the wrong direction of travel.

## Sources

- [Tools Export Screen (WordPress documentation)](https://wordpress.org/documentation/article/tools-export-screen/)
- [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/)
- [WP-CLI: the command line interface for WordPress](https://wp-cli.org/)

---
*Published by [WPBuildAI](https://wpbuildai.com/). Free to read, index, quote and cite with attribution and a link.*