How WordPress Works

Wordpress Manual WordPress Fundamentals Toggle WordPress Fundamentals section What Is WordPress? WordPress.org vs WordPress.com What Can You Build with WordPress? How WordPress Works WordPress Core, Themes, Plugins and Content Essential WordPress Terminology How to Plan a WordPress Website Domains, Hosting, DNS and HTTPS Explained How to Choose WordPress Hosting Development, Staging and Production Environments How…

6 min read

  • Article
  • Beginner
  • 6 minutes read
  • Reviewed August 3, 2026

WordPress generates web pages by combining a request from a visitor with content, settings, code and templates stored on a server.

The process happens quickly, but understanding its main stages helps explain why hosting, themes, plugins, caching and databases all affect a WordPress website.

A Visitor Requests a URL

The process begins when someone opens a URL in a browser.

For example:

https://example.com/services/website-design/

The browser needs to discover which server is responsible for the domain. DNS records connect the domain name to the relevant hosting infrastructure.

The browser then establishes a connection. On an HTTPS website, that connection is encrypted and the server presents a valid TLS certificate for the domain.

The Web Server Receives the Request

The hosting environment runs web server software, commonly Apache or Nginx, or another compatible server stack.

The web server receives the request and determines how it should be handled. Static files such as an existing image may be returned directly. A normal WordPress page request is passed into the WordPress application.

Server configuration, rewrite rules and WordPress permalink handling help translate a readable URL into a request that WordPress can understand.

PHP Runs WordPress

WordPress core is primarily written in PHP.

PHP executes on the server. It loads the WordPress environment, reads configuration, initializes active plugins, processes the requested URL and prepares the response.

Visitors do not normally receive the PHP source code. They receive the generated output, typically HTML along with references to CSS, JavaScript, images and other assets.

WordPress Reads Its Configuration

The wp-config.php file contains essential configuration values, including database connection information and security-related constants.

WordPress uses this information to connect to the database and initialize the installation.

Additional behavior can be influenced by server configuration, environment variables, must-use plugins, active plugins, the selected theme and custom code.

WordPress Loads Core, Plugins and the Theme

WordPress follows an initialization process.

At a simplified level, it:

  1. Loads core files.
  2. Connects to the database.
  3. Loads must-use and network-activated plugins where applicable.
  4. Loads active plugins.
  5. Determines the requested content and query.
  6. Loads the active theme.
  7. Selects an appropriate template.
  8. Generates the response.

Plugins can attach functions to WordPress hooks during this process. They may register content types, change queries, add fields, integrate services, enforce permissions or alter the final output.

The theme provides templates and presentation rules used to render the requested page.

WordPress Queries the Database

The database stores much of the website’s content and configuration.

Depending on the request, WordPress may retrieve:

  • A post or page.
  • Metadata associated with content.
  • Categories, tags or custom taxonomy terms.
  • User information and permissions.
  • Website options.
  • Navigation data.
  • Comments.
  • Plugin-specific records.

A single page can require several database queries. Plugins and themes can introduce additional queries, which is one reason architecture and performance quality matter.

WordPress Determines What the Request Represents

A URL may represent different kinds of content:

  • The front page.
  • A single post.
  • A page.
  • A custom post type entry.
  • A category or taxonomy archive.
  • A search result.
  • An author archive.
  • A date archive.
  • A not-found response.

WordPress builds a main query that describes the requested content. The theme then uses that context to select a template through the template hierarchy.

The Theme Generates the Page Structure

The active theme determines how the request is presented.

A classic theme may use PHP template files such as single.php, page.php, archive.php or more specific templates.

A block theme uses block templates and template parts, with configuration and styles that can be managed through the Site Editor and theme.json.

The selected template typically outputs:

  • Document structure.
  • Header and navigation.
  • Main content.
  • Sidebars or supplementary areas.
  • Footer.
  • Styles and scripts.

The content itself remains stored in the database, while the theme determines how that content appears.

The Server Sends a Response

After WordPress and the theme generate the page, the server returns an HTTP response to the browser.

The response includes a status code, headers and a body.

Common status codes include:

  • 200 for a successful response.
  • 301 or 302 for a redirect.
  • 403 when access is forbidden.
  • 404 when a resource is not found.
  • 500 when a server-side error occurs.

The browser reads the HTML, requests referenced assets and renders the page.

The Browser Builds the Visible Website

The browser processes:

  • HTML for structure and content.
  • CSS for presentation.
  • JavaScript for interactions and dynamic behavior.
  • Images, fonts, video and other media.

Some scripts may make additional requests after the initial page loads. These can retrieve data through the WordPress REST API, submit forms, load analytics or update interactive components.

Where Caching Fits In

Without caching, WordPress may repeat much of this process for every request.

Caching stores reusable results at different layers, such as:

  • Browser cache.
  • Content delivery network cache.
  • Full-page cache.
  • Reverse proxy cache.
  • Object cache.
  • PHP opcode cache.

A cached page may be served before WordPress performs a full request. This can improve performance, but caches must be cleared or invalidated when content and configuration change.

How the Administration Area Works

The WordPress administration area uses the same installation, database, user system and plugin environment as the public website.

Authenticated users can create content, change settings and perform actions according to their capabilities.

When an editor publishes a page, WordPress stores the content and related data. A visitor later requests the public URL, and WordPress retrieves that information through the process described above.

The administration interface and public frontend are therefore two views of the same underlying system.

Dynamic Does Not Mean Every Page Is Rebuilt Identically

WordPress is commonly described as a dynamic CMS because pages are generated from stored data and templates.

In practice, modern WordPress websites may combine:

  • Dynamically generated pages.
  • Cached HTML responses.
  • Static assets.
  • API responses.
  • Server-rendered blocks.
  • Client-side JavaScript.
  • External services.

The architecture depends on the website, hosting stack and extensions in use.

A Simplified Request Flow

The complete process can be summarized as:

  1. A visitor requests a URL.
  2. DNS directs the request to the hosting infrastructure.
  3. The web server receives the request.
  4. PHP loads WordPress.
  5. WordPress connects to the database.
  6. Core and plugins process the request.
  7. WordPress identifies the requested content.
  8. The theme selects a template and generates output.
  9. The server returns the response.
  10. The browser loads assets and renders the page.

Understanding this flow makes later topics easier, including caching, template hierarchy, plugin conflicts, rewrite rules and debugging.

Frequently Asked Questions

Does WordPress create a physical HTML file for every page?

Usually no. WordPress stores content and generates responses dynamically, although caching systems may store generated HTML for reuse.

Where is page content stored?

Most page and post content is stored in the database. Uploaded media and code normally live in files, while database records reference and configure them.

Why can a plugin break the frontend and the dashboard?

Active plugins load as part of the same WordPress installation and can affect queries, output, permissions, scripts and administration behavior.

Why does changing a theme change the site without deleting content?

The content is generally stored separately from the theme. The new theme uses different templates and styles to present the same underlying records, although theme-specific features can complicate a switch.

Continue Learning

Previous: What Can You Build with WordPress?

Next: WordPress Core, Themes, Plugins and Content