Where Are WordPress Pages Stored?
performance
If you've ever wondered where are WordPress pages stored, the answer surprises most people. Your page content doesn't sit in a folder on your server. It lives inside a MySQL database, while your server's file system handles themes, plugins, and uploaded media separately. The sections below explain each storage layer and why the distinction matters for backups, performance, and troubleshooting.
Key Takeaways
- WordPress stores your page content inside a MySQL database table called wp_posts, not as individual files on your server.
- Your server's file system holds themes, plugins, and uploaded media — the presentation layer around your content, not the content itself.
- Every page visit triggers a database query and a PHP template merge before a caching layer serves the result to your visitor.
- Knowing where your pages live is the foundation for reliable backups, clean migrations, and faster troubleshooting.
- Get plain answers to common questions about WordPress storage, from recovering deleted pages to fixing database connection errors.
Where Does WordPress Store Pages? It's All in the Database
WordPress database storage is the starting point for any honest answer to this question. When you publish a page, the content doesn't get written to a text file or an HTML document on your server. It gets written to a row inside a MySQL database, or MariaDB depending on your hosting setup.
The table that holds your page content is called wp_posts. This single table stores pages, blog posts, and custom post types. WordPress tells them apart using a column called post_type. A blog post carries the value post. A static page carries the value page. The data lives in the same table either way.
What's Actually Inside the wp_posts Table?
The wp_posts table has several columns that define each piece of content. The post_content column holds the full body of your page. If you're using the block editor, that includes the serialized block markup. The post_title column stores the page title. The post_status column tracks whether the page is published, in draft, scheduled, or in the trash.
Two related tables extend what wp_posts stores. The wp_postmeta table holds custom fields and metadata for individual pages, such as SEO settings or plugin data. The wp_options table stores site-wide settings like your active theme, site title, and permalink structure.
This matters most when you're moving a site. A database export without wp_posts is not a backup of your pages. It's a partial snapshot that won't restore your content.
If you query the database using phpMyAdmin or WP-CLI, your page content is readable as plain text. Filter by post_type = 'page' to separate pages from posts and other content types. Most hosting environments give you this access, though the path to get there depends on your setup.
Where WordPress Pages Are Stored on the File System
The WordPress file system holds everything except your page content. Themes, plugins, and uploaded media all live in files on your server, not in the database.
Your WordPress installation typically sits inside a directory called public_html or www on shared hosting. On a VPS, the path may differ, but the internal folder structure stays the same regardless of where WordPress is installed.
Inside that root directory, wp-content is where most of the relevant files live. The wp-content directory splits into three main subfolders. The themes folder holds your installed themes, including the active one. The plugins folder holds every plugin you've installed. The uploads folder holds images, PDFs, videos, and other media added through the WordPress media library.
How Hosting Environment Affects File and Database Access
How you reach these files depends on your hosting type. On shared hosting with cPanel, you access the file system through File Manager and the database through phpMyAdmin. On a VPS, you'd use SSH for the file system and connect to MySQL through the command line.
Managed WordPress hosting often removes direct access to both layers. The host replaces phpMyAdmin and SSH with its own tools. Your data is still in the same place. You just reach it through a different interface.
WordPress page templates live inside the active theme folder at wp-content/themes/your-theme-name/. These PHP files define the layout for different page types. When WordPress builds a page, it pulls content from the database and passes it through one of these template files to produce HTML. The template handles presentation. The database handles content.
Uploaded media files sit at wp-content/uploads/, organized into subfolders by year and month. A file uploaded in June 2024 lives at wp-content/uploads/2024/06/. The database stores the URL reference to that file. The actual file lives on the server.
This separation is why switching themes doesn't erase your pages. The content stays in the database. Only the presentation layer changes.
How WordPress Stores Page Content and Serves It to Visitors
How WordPress builds a page starts the moment someone types your URL into a browser. The database holds your content, but WordPress doesn't send raw database rows to visitors. It assembles each page on request, pulling from both the database and the file system.
A file called .htaccess in your WordPress root directory routes incoming requests to WordPress's routing system. WordPress reads the URL, identifies which page is being requested, and runs a query against wp_posts.
The file wp-config.php makes that query possible. It holds your database name, username, password, and host. WordPress reads these credentials on every page request. If wp-config.php has incorrect values, or if the database server is unreachable, WordPress throws the "error establishing a database connection" message instead of loading the page.
Once the query runs, WordPress retrieves the content, title, and metadata for the requested page. It passes that data to a PHP template in your active theme. The template wraps the content in HTML, adds your site's header and footer, and sends the finished page to the browser.
Where Cached Pages Live and Why It Matters
Caching changes where pages are served from, not where they're stored. Caching plugins like WP Super Cache and WP Rocket take the assembled HTML output and save a static copy to wp-content/cache/. The next visitor gets that file directly, without triggering a database query or template rendering.
Server-level tools operate differently. Redis and Memcached store database query results in memory. Varnish caches full page responses at the network level, before the request even reaches WordPress.
CDN caching adds another layer. A content delivery network stores copies of your pages on servers in multiple locations. A visitor in Tokyo gets the page from a nearby server, not from your origin host.
These layers explain a common frustration: you update a page, but visitors still see the old version. The database has the new content. The cache is still serving the old copy. Clearing the cache forces WordPress to rebuild the page from the database.
The Bottom Line
Your WordPress pages exist across three layers. The database holds your content in wp_posts. The file system holds your themes, plugins, and uploads. The cache holds a pre-built copy that visitors actually receive. Each layer has a distinct job, and a problem in any one of them produces a different symptom. A database issue breaks page loading. A file system issue breaks layout or functionality. A cache issue serves stale content. A complete backup covers both the database and the file system. If you want guidance on how your specific hosting setup manages these layers, a WordPress professional can help you sort out the details.
Related reading
FAQs
Can I recover a deleted WordPress page from the database?
Deleted pages remain in the database with a post_status of trash until you empty the trash. You can restore them through the WordPress dashboard under Pages, or directly in the database using phpMyAdmin by changing the status back to publish.
What does "error establishing a database connection" mean?
This error means WordPress can't connect to your MySQL database. The most common causes are incorrect credentials in wp-config.php, a database server that is down, or a corrupted database. Check your database name, username, password, and host values first.
How do I export my WordPress pages from the database?
Select your database in phpMyAdmin and choose the Export option to download a .sql file. You can also run wp db export using WP-CLI from the command line. Both methods capture your full database, including all page content stored in wp_posts.
Do post revisions affect where WordPress page content is stored?
Yes. Each time you save a page, WordPress adds a revision row to wp_posts. These rows accumulate over time and increase the table's size. A large table slows database queries. Database optimization plugins can delete old revisions and reduce that bloat.
What do I need to back up to save all my WordPress pages?
You need two things: the MySQL database, which contains your page content, and the file system, which contains your themes, plugins, and uploaded media. Backing up only one leaves your site incomplete and difficult to restore.
See What's Included With Nova Managed Hosting
Nova runs every managed WordPress tenant in an isolated Kubernetes namespace with daily automated backups and managed core/plugin updates. If you're troubleshooting a specific issue on your own site, our team can help.