How to Find Content in a WordPress Export ZIP File (2026 Complete Guide)

Written by a WordPress developer with 10+ years of migration experience.

You just exported your entire WordPress site. You unzipped the file, ready to see all your hard work—your posts, your images, your customizations. Instead, you’re staring at a single, cryptic .xml file. Panic sets in. Did the export fail? Is your content gone forever?

Take a deep breath. Your website isn’t lost. In fact, your content is exactly where it should be.

The problem isn’t a corrupted file or user error; it’s a fundamental misunderstanding of how WordPress actually packages your site. This guide will not only show you exactly where your content is hiding, but also explain why it’s there, so you never have to feel this panic again.

Why You Can’t Find Content in Your Exported WordPress ZIP File

Nearly every case of missing content from an exported ZIP boils down to three pain points: split content and media files, an XML structure that’s unreadable at a glance, and broken images/content after import. All these issues trace back to a misalignment with how WordPress’s export system is designed to work.

WordPress’s content system is built on a dual structure of database-driven content + file system assets:

• Database-driven content: This includes your posts, page copy, categories, tags, comments, custom fields, SEO metadata, and other structured content. It is never stored as standalone text files, but in your site’s MySQL database. The native WordPress export tool packages this data into an XML file using a specialized protocol (WXR), which is the core file you’ll see after unzipping your export.
• File system assets: This includes media attachments (images, videos, PDFs), theme files, plugin code, and custom styles. These files live in fixed directories on your web server, and are not included in the native WordPress export ZIP by default.

Think of it like having a book’s table of contents and chapter outlines—but none of the actual text or pictures. That’s what the native WordPress export ZIP provides: a structured index, not a full site clone. It requires specific parsing methods to fully restore and access your content.

First Step: Identify What Type of ZIP File You Have

This is the foundational step, where 80% of users go wrong. ZIP files generated by different tools have completely different structures and require entirely different methods to locate content.

There are only two primary types of WordPress export ZIP files. Use this quick comparison table to identify yours in 10 seconds after unzipping:

Here’s a visual representation of what you’ll find inside each ZIP type:

Native Export ZIP:
wordpress.zip
 └── wordpress.2026-03-05.xml   (all your text content in WXR format)

Full Backup ZIP:
full-backup.zip
 ├── wp-content/
 │   ├── uploads/                (all media files, organized by year/month)
 │   ├── themes/                  (all theme files)
 │   └── plugins/                 (all plugin files)
 ├── database.sql                 (full database dump)
 ├── wp-admin/                    (WordPress core)
 └── wp-includes/                 (WordPress core)

Once you’ve confirmed the ZIP type, you’ll know where to find website content within exported WordPress ZIP—whether it’s in the XML file or the database backup.

Native WordPress Export ZIP: Structure Breakdown & Content Location

Many users panic when they unzip a native export ZIP and only see a single XML file, assuming the export failed. In reality, this code-heavy file is the goldmine of your site’s content. Below is a full breakdown of its structure, what it includes, what it doesn’t, and how to quickly locate the content you need.

Standard Structure of a Native Export ZIP

After unzipping, you’ll see a core XML file. Exports generated with extended plugins may also include additional folders for media or custom settings, with the full structure as follows:

├── wordpress.xml          # Primary post content metadata file
├── media-library/         # Media files (included only with extended export plugins)
└── wp-content/            # Theme/plugin files (included only with extended export plugins)

The vast majority of post content resides in wordpress.xml. It uses the WordPress eXtended RSS (WXR) format—a specialized XML-based protocol designed by WordPress for sharing content between sites. Think of it as a ‘language’ that WordPress uses to talk to other WordPress sites. It is built for cross-site parsing by the WordPress system, not for direct human reading—but with the right tag references, you can quickly locate your target content.

What Is Included in the XML File

This file contains the full package of your site’s database-driven content. Every <item> tag corresponds to a single piece of content. You can open the file with a text editor like VS Code or Sublime Text, and use the tags below to quickly filter your content:

• Blog posts: Corresponding to <item> tags with post_type="post". The post title is in the <title> tag, and the full post content is in the <content:encoded> tag.
• Static pages: Corresponding to <item> tags with post_type="page".
• Media attachments: Corresponding to <item> tags with post_type="attachment". These tags include the file URL, upload date, and metadata, but not the actual media source files.
• Additional content: Categories, tags, navigation menu structures, comment data, custom post types, custom fields, and public author information are all stored in their corresponding XML tags. SEO configurations and custom field data are housed within the <wp:postmeta> tag.

What Is NOT Included in the XML File

It’s critical to note that the native export XML file is intentionally built without the following content, so it is completely normal if you cannot locate these items:

• Actual media source files (images, videos, PDFs) — only URL references are included
• Theme files, custom styles, and template modifications
• Plugin source files and configuration data
• Sensitive user data such as password hashes — only public data like usernames and email addresses are retained
• WordPress core system files and global site configurations
• Site customizer settings (typically stored in the database, though some backup plugins may export them as JSON configuration files)

Full Backup ZIP: Fixed Paths for All Your Site Content

If you have a full backup ZIP generated by a plugin or hosting control panel, all your site content lives in fixed, predictable paths. There’s no need to scroll aimlessly through folders—follow the corresponding paths below to locate your target content with 100% accuracy.

1. Database-Driven Content & Global Configurations
   All your posts, pages, comments, categories, site settings, plugin configurations, and theme settings are stored in the SQL dump (a file with .sql extension, typically named with your domain and backup date). This is a full snapshot of your site’s database. Every piece of content included in the native XML file is fully covered in this SQL file.
2. Media Attachment Files
   All images, videos, PDFs, and attachments uploaded to your site are stored in the fixed directory wp-content/uploads. WordPress organizes these files into year and month subfolders by default (for example, 2026/03/), and every image and resource file from your posts lives here. To restore media, simply copy the entire uploads folder.
3. Theme & Custom Template Files
   Your active theme, all installed themes, and any code modifications or custom templates are stored in wp-content/themes. Copying this entire folder preserves all your theme settings and customizations.
4. Plugin Source Files
   The source files for all installed plugins are stored in wp-content/plugins. When paired with the plugin configuration data in the SQL dump, this fully restores all plugin functionality and settings.

5-Step Practical Guide to Extract Primary Website Content From Your ZIP

Based on extensive migration experience, I’ve simplified the process of locating and extracting content into 5 actionable steps. No matter which type of ZIP file you have, following these steps will help you accurately locate and extract your content.

Step 1: Identify Your ZIP Type to Lock in the Right Location Method

Beginner Tip: Use the comparison table in the previous section. If you see an XML file only, it’s a native export. If you see folders like wp-content and an SQL file, it’s a full backup.

Correctly identifying your ZIP type eliminates 80% of common content-location mistakes.

Step 2: Locate Your Core Text Content

Your primary text content lives in either the XML file (native exports) or the SQL dump (full backups).

• For native export packages: Open the XML file in a text editor. Use the <item> tag to filter content. Search for your post title keywords to locate corresponding posts and pages.
• For full backup packages: Locate the SQL dump. To view all posts, pages, and configuration data, import it into a database via phpMyAdmin:
  1. Open phpMyAdmin and select your target database.
  2. Click the Import tab.
  3. Choose your SQL file and click Go.

  Alternatively, open the SQL file with a text editor and search for post titles to verify content.

Beginner Tip: You don’t need to edit the XML/SQL file directly. The official WordPress Importer handles all parsing automatically when you upload the file (for XML). For SQL, phpMyAdmin handles the import process.

Step 3: Filter Target Content Precisely

• For casual users: Use keyword searches directly in your text editor (e.g., a post title or core paragraph) to quickly locate the corresponding <item> tag and copy the relevant content.
• For users with basic technical knowledge: Use XPath syntax for fast filtering. XPath is a query language for navigating XML documents. For example:
  • //item[@post_type='post'] isolates all blog posts.
  • //item[@post_type='page'] isolates all static pages.
  • //item[contains(title, 'KEYWORD')] searches for content containing a specific keyword.

Note: WXR XML files include namespace declarations (e.g., xmlns:wp="http://wordpress.org/export/1.2/"). When using XPath tools, you must register the wp and content namespaces, or your queries may return empty results. Most online XPath testers allow namespace registration.

Step 4: Locate and Restore Your Media Files

Media files are never included in native exports, and are only found in the wp-content/uploads directory of full backup packages or your original server.

• For native export packages: The XML only contains media URLs, not the actual files.
  • If your original site is still live, the WordPress Importer can automatically fetch files during import (see Step 5).
  • If the original site is offline, you must retrieve the source files from the wp-content/uploads directory of your original server (via FTP or hosting file manager).
• For full backup packages: Open the wp-content/uploads folder directly, locate all media files in the year/month subdirectories, and copy the entire folder to fully restore your media.

Step 5: Restore Content and Verify Completeness

• For native export packages:
  1. Go to your new site’s admin dashboard → Tools → Import → WordPress.
  2. Install the official WordPress Importer if prompted.
  3. Upload your XML file. The system will automatically parse and rebuild your content structure.
  4. Important: If your original site is still live, the importer will attempt to download media attachments. Ensure the “Download and import file attachments” option is enabled (it is by default in recent versions).

  Note on file size limits: If your XML file exceeds your host’s PHP upload limit (e.g., > 2MB, 8MB, etc.), you may encounter timeouts or errors. Solutions:

  • Use WP-CLI (WordPress Command Line Interface): wp import wordpress.xml --authors=create
  • Split the XML using a WXR file splitter (e.g., the “WXR Splitter” plugin or online tools).
  • Ask your host to increase the upload limit temporarily.
• For full backup packages:
  1. Import the SQL dump into your new database. To import via phpMyAdmin:
     a. Open phpMyAdmin and select your target database.
     b. Click the Import tab.
     c. Choose your SQL file and click Go.
  2. Overwrite the wp-content folder to the corresponding directory on your new site.
  3. Update the database connection details in wp-config.php.
  4. If you are moving to a new domain, you must update the site URLs in the database. Use a plugin like Better Search Replace to safely replace the old domain with the new one (see the next section for details).

Validation checks:

1. Visit your new site’s frontend, open a post that previously included images, and confirm images load correctly and formatting is intact.
2. Navigate to the admin dashboard’s Media Library to verify all media files are present.
3. Check that all pages, categories, and navigation menus appear as expected.
4. Verify that internal links point to the correct URLs (especially if you changed domains).

Beginner Tip: For domain changes, always run a dry run with Better Search Replace first to see what will be replaced. Then run the live update and clear your site cache.

Media File Issues? Scenario-Based Solutions for Common Problems

Missing media files, broken image previews, and unplayable videos are the most frequent issues during export and import. Below are scenario-based solutions for every common problem, all tested and validated in real-world migrations.

Advanced Tips: Developer-Focused XML Parsing & Content Extraction

If you need to process large volumes of content, or programmatically extract content from your export file, manual operations are inefficient. Below are the parsing methods I use regularly for client work, which drastically reduce processing time.

1. Bulk XML Parsing with Python (Basic Error Handling)

"""
This script uses the built-in xml.dom.minidom module. No extra installation needed.
For the second example, you'll need lxml: pip install lxml
"""

from xml.dom import minidom

# Add try-except block to handle XML formatting errors
try:
    dom = minidom.parse('wordpress.xml')
except Exception as e:
    print(f"XML parsing failed: {e}")
    exit(1)

items = dom.getElementsByTagName('item')

# Loop through all items to extract post title and content
for item in items:
    # Filter for blog post post type
    post_type_elements = item.getElementsByTagName('wp:post_type')
    if post_type_elements and post_type_elements[0].firstChild:
        post_type = post_type_elements[0].firstChild.data
        if post_type == 'post':
            title_elements = item.getElementsByTagName('title')
            content_elements = item.getElementsByTagName('content:encoded')
            if title_elements and title_elements[0].firstChild and content_elements and content_elements[0].firstChild:
                title = title_elements[0].firstChild.data
                content = content_elements[0].firstChild.data
                print(f"Post Title: {title}")
                print(f"Post Content: {content}\n")

2. Extract Published Posts to CSV with Python

"""
Example: Extract all published posts and save to a CSV file.
Requires lxml: pip install lxml
"""

import csv
import lxml.etree as ET

# Parse XML file with error handling
try:
    tree = ET.parse('wordpress.xml')
except Exception as e:
    print(f"XML parsing failed: {e}")
    exit(1)

# Isolate only published blog posts
# Note: XPath with namespaces requires prefix mapping
namespaces = {'wp': 'http://wordpress.org/export/1.2/', 'content': 'http://purl.org/rss/1.0/modules/content/'}
published_posts = tree.xpath('//item[wp:post_type="post" and wp:status="publish"]', namespaces=namespaces)

# Write to CSV
with open('posts.csv', 'w', newline='', encoding='utf-8') as csvfile:
    writer = csv.writer(csvfile)
    writer.writerow(['Title', 'Content'])  # Write CSV header
    for post in published_posts:
        title = post.find('title').text
        content = post.find('content:encoded', namespaces).text
        writer.writerow([title, content])

3. Direct Database Queries for Faster Content Access

If you have database access to your original site, querying the wp_posts table directly is significantly more efficient than parsing XML, especially for sites with large volumes of content:

-- Query all published posts and pages, extract ID, title, and content
-- Note: Replace 'wp_' with your custom database table prefix if you modified it during installation.
SELECT ID, post_title, post_content 
FROM wp_posts 
WHERE post_type IN ('post','page') 
AND post_status = 'publish';

4. Version Compatibility Handling

XML files exported from different WordPress versions may use varying namespace prefixes (such as wp:, content:, or excerpt:) or include incompatible new fields. To avoid parsing failures and content loss:

• Check the WordPress version of the export site by looking at the wp-includes/version.php file or the site's admin footer.
• Test imports in a WordPress environment with the same version as the export site. If that's not possible, the WordPress Importer is generally backward-compatible, but you may encounter issues with very old exports (pre-3.0). In such cases, consider upgrading the export file by importing it into a temporary site of a newer version and re-exporting.

3 Critical Pre-Export Checks to Eliminate Content Loss

I learned these lessons through difficult experiences in early migrations. Now, I perform these three checks for every client export and have eliminated content loss entirely.

1. Match Your Export Tool to Your End Goal
   If you’re only migrating post content to a new site, the native WordPress export tool is fully sufficient. But if you’re switching hosting providers, decommissioning an old site, or creating a full disaster recovery backup, always use a professional full-site backup plugin like UpdraftPlus or Duplicator. This ensures your database, media files, themes, and plugins are packaged together in one file, eliminating content separation issues.
2. Create Redundant Backups for Your Media Files
   No matter which export tool you use, always create a separate backup of the wp-content/uploads folder. Typical server paths:
   - Linux: /var/www/html/wp-content/uploads
   - Windows: C:\inetpub\wwwroot\wp-content\uploads
   Note: Your actual paths may vary based on your server configuration.
   This backup saved me when an original site went down immediately after an XML export, rendering all image links useless.
3. Validate the Integrity of Your Export File
   After export, always complete an integrity check to avoid discovering a corrupted file during import.
   - For native export XML files: Open the file in a text editor and scroll to the end to confirm the closing </rss> tag is present.
   - For full backup ZIP files: Unzip it locally first to confirm there is no compression corruption and the full directory structure is present before using it for migration.

Quick Reference Checklist

Save this checklist for your next WordPress export or migration to avoid common mistakes:

• ☐ Identify your ZIP type (native export vs full backup) before doing anything else
• ☐ For native exports: Confirm the XML file has a closing </rss> tag for integrity
• ☐ For full backups: Verify the ZIP includes an SQL dump and wp-content folder
• ☐ Create a separate backup of the wp-content/uploads folder for media redundancy
• ☐ Enable "Download and import file attachments" in WordPress Importer (for live sites)
• ☐ For domain changes: Use Better Search Replace to update URLs (dry run first)
• ☐ Validate your migration by checking frontend image loading, Media Library completeness, and menu functionality
• ☐ Test imports in a staging environment first for large or high-traffic sites
• ☐ For large/high-traffic sites: Consider using WP-CLI for import/export operations to avoid web server timeouts and enable finer process control

Frequently Asked Questions (FAQ)

Can I restore a full WordPress site from only the XML export file?

No. The XML export contains only your database content (posts, pages, comments, etc.). It does not include media files, themes, plugins, or WordPress core. To restore a full site, you need a full backup (SQL dump + wp-content folder) or use a backup plugin.

Why is my WordPress export ZIP file so small?

A native export ZIP is small because it only contains a text-based XML file (often just a few MB). Media files (images, videos) are not included. If you need a larger file with all media, use a full backup plugin.

How do I open and read a WordPress WXR/XML file?

You can open it with any text editor (VS Code, Sublime Text, Notepad++). For easier reading, you can use an XML viewer or parse it with tools like Python or an online WXR viewer. However, the WordPress Importer is designed to read it automatically.

Can I extract images directly from a WordPress export XML file?

No. The XML file only contains URLs pointing to images. To get the actual image files, you must retrieve them from the wp-content/uploads directory on your original server or from a full backup.

What do I do if my XML file is too large to import?

If your XML exceeds your host’s upload limits, try:

• Using WP-CLI: wp import wordpress.xml --authors=create
• Splitting the XML with a WXR file splitter.
• Asking your host to temporarily increase the PHP upload limit (e.g., upload_max_filesize and post_max_size).

What’s the difference between a WordPress native export and a full site backup?

A native export (Tools → Export) creates an XML file with your site’s content (posts, pages, etc.) but no media or system files. A full site backup (via plugin or hosting) includes everything: database, media, themes, plugins, and sometimes core files. Choose based on your goal: content migration vs. complete site restoration.

Final Thoughts

Understanding where to find website content within exported WordPress ZIP files is the key to seamless migrations. Learning to locate your content ultimately comes down to understanding the underlying logic of WordPress' content storage architecture. WordPress' content system is always a dual structure of database-driven content and file system assets: dynamic text content lives in the database/XML file, and static physical files live in the wp-content directory. One cannot fully restore a site without the other.

That XML file that looks like unintelligible code at first glance is not useless—it’s a full snapshot of all your site’s text content. The folder structure that looks overwhelming has fixed, predictable paths that let you locate exactly what you need, once you know where to look.

From being completely stuck on a ZIP file in my early days, to handling complex multisite networks and WooCommerce migrations, I’ve navigated every pitfall there is. The truth is, WordPress backups and migrations are not advanced technical skills—once you understand the underlying logic and follow the right steps, you can handle them with confidence.

If you run into edge cases during your process, or encounter export scenarios not covered in this guide, feel free to share your experience in the comments. WordPress' ecosystem is incredibly diverse, and there are always new scenarios to explore and solve together.

Was this guide helpful? Let us know with a click below, and share your WordPress migration questions in the comments.

Glossary