The WordPress Server Stack

Four layers sit under a WordPress site, and almost every hosting question is really about which layer owns the problem. The web server accepts the request, PHP builds the page, the database answers PHP's questions, and a cache tries to prevent all of that. Getting the division clear is the difference between a useful support ticket and a week of guessing.

What each layer actually does

Read the symptom column when something breaks. Error establishing a database connection is the database layer and no amount of PHP tuning helps; a white screen is almost always PHP, and the server log will say so.

Nginx and Apache, and the .htaccess trap

Apache reads a .htaccess file in each directory, so WordPress can write its own rewrite rules and plugins can add redirects and header rules without touching server configuration. That is convenient and slightly slow, because the file is read per request.

Nginx does not read .htaccess at all. The equivalent rules live in the server configuration, which you usually cannot edit on shared hosting.

The practical consequences catch people out constantly:

• Permalink fixes that say "re-save your permalinks" work on Apache and do nothing structural on Nginx, where the rewrite must already be in the config — the background is in permalinks not working.
• Plugin-generated redirects written to .htaccess are silently ignored.
• Security rules blocking access to wp-config.php or the uploads directory need a server-side equivalent.

Many hosts run Nginx in front of Apache, which gets you both behaviours and one more layer to reason about. Ask your host which arrangement you are on before debugging anything that involves rewriting URLs.

PHP: version, memory and workers

Version matters for both speed and security. Old PHP is unsupported PHP, and a site left behind eventually meets a version bump it cannot survive — a site broken after a PHP update is the aftermath, and checking your WordPress version is where to start on the WordPress side.

Memory is a per-process limit. Raising it fixes imports and image processing and does nothing for speed — increasing the memory limit covers when it is the right lever.

Workers are the ceiling nobody sees on the hosting comparison page. Each worker runs one PHP request at a time; ten workers means ten simultaneous uncached requests, and the eleventh visitor waits. This is why a site with a page cache can serve thousands of anonymous readers on modest hosting, and why a shop or a membership site — where every request is personal and uncacheable — needs far more capacity for the same traffic. It is the question to ask when choosing hosting or managed hosting, rather than asking about storage.

The database

WordPress is query-heavy by design. Two things affect it most:

• The wp_options table, and specifically autoloaded options. Plugins that store large autoloaded values make every single request slower, including cached-miss requests. It is the first thing to inspect on a mysteriously slow site.
• Table size and indexes, which matter once posts, orders or log tables grow past the point where a full scan is cheap.

MySQL and MariaDB are interchangeable for WordPress purposes. Repair and maintenance behaviour differs slightly by engine, and repairing a WordPress database covers the practical steps.

Caching: two different things called cache

Page caching stores finished HTML so PHP never runs. It is enormously effective for anonymous visitors and does nothing for logged-in ones.

Object caching — Redis or Memcached — stores the results of database queries in memory, so PHP runs but asks the database less. This is the layer that matters on sites where visitors are logged in: shops, courses, forums, communities.

A site with a page cache and no object cache is fast for readers and slow for members. Knowing which of your visitors is which decides where the money goes. The plugin-level view is in cache plugins, and WP Rocket is worth reading specifically for the overlap between plugin and server caching, which is a common cause of changes not showing.

Telling which layer is failing

1. Read the actual error, not the browser's summary — enable debug mode and check the PHP error log.
2. 502 or 504 points at the web server failing to get an answer from PHP: workers exhausted, or a request that ran too long.
3. A blank page with a 200 is usually PHP fatal with display off.
4. Slow admin, fast front end points at the database or object caching, because admin pages are never page-cached — see speeding up wp-admin.
5. Static files fine, pages slow means PHP or the database, never the network.

Common mistakes

• Editing .htaccess on an Nginx host and concluding WordPress is broken.
• Raising the memory limit to fix a speed problem.
• Buying more storage when the constraint was PHP workers.
• Running two page caches, one at the host and one in a plugin.
• Ignoring autoloaded options on a site that has accumulated years of plugins.

Verify

Check which server you are on — the response headers usually say — and confirm whether .htaccess has any effect at all. Look up the PHP version and worker count in the hosting panel. Run a query on wp_options to see the total autoloaded size. Then load a page as an anonymous visitor and as a logged-in one and compare: the gap between those two numbers tells you whether your problem is caching or capacity.