You migrate WordPress from OVH shared hosting to a VPS. On shared hosting, Apache + .htaccess hid a broken permalinks config. On Nginx, the homepage returns 404 until you translate rewrite rules into /etc/nginx/sites-available/. It is not Nginx that is "harder" — scattered configuration no longer travels with you.
Apache and Nginx are two ways to serve PHP and static files. For WordPress, the operations question boils down to: who manages rewrite rules, how PHP is isolated, and how you cache under load.
mod_php, PHP-FPM: the real choice
| Stack | WordPress advantages | Operations friction |
|---|---|---|
| Apache + mod_php | Plugin .htaccess, shared-hosting simplicity | Memory per Apache process, scale-up |
| Apache + PHP-FPM | .htaccess compatibility + PHP isolation | Two services to tune |
| Nginx + PHP-FPM | Performance, low footprint | No .htaccess; admin config |
| Nginx + Apache backend | Rare today | Double stack to maintain |
Choosing Apache "for WordPress" in 2026 often means choosing
.htaccess— not a CMS requirement.
Apache: when it still simplifies
Classic shared hosting. The host manages everything; you upload plugins without touching the server.
Plugins rewriting .htaccess (cache, security, redirects) — on Apache, they "just work".
Team without root access. No Nginx file to edit.
Limits: under load, mod_php multiplies RAM; switch to PHP-FPM recommended from VPS onward.
Nginx: when it simplifies production
Media or e-commerce traffic. Fewer workers, better static file service, modern TLS configs.
Unified stack. Same Nginx in front of PHP, Node, or upstream cache.
Managed WordPress hosting. Raidboxes, Kinsta, etc.: Nginx + integrated cache — you do not maintain rewrites by hand.
Apache → Nginx migration checklist:
- Export WordPress permalinks (Settings → permalinks → save)
- Translate standard
try_files+@wordpresspattern - Check
client_max_body_sizefor uploads - Test wp-admin, REST API, cron
Cache: where operations really play out
Server choice matters little without page cache:
- Plugin (WP Rocket, etc.) + Nginx gzip/brotli compression
- Redis object cache for heavy admin
- CDN for assets
Aggressive cache on shared Apache often beats a poorly tuned bare Nginx.
The peak: the web server is usually not your bottleneck
Decide and move forward without blind spots
On shared hosting without root, Apache is often imposed: optimise plugin cache and database. On VPS with an ops team, prefer Nginx + PHP-FPM with a documented, versioned WordPress template. For high traffic without internal team, managed Nginx WordPress — see Raidboxes cache — avoids manual rule translation. Test identical load on both stacks before migration. Browse the directory and comparison tool; logical follow-up: PHP-FPM or mod_php.
Frequently asked questions
Does WordPress recommend Apache or Nginx?
WordPress runs very well on both. Apache is the historical shared-hosting default thanks to .htaccess. Nginx is common on VPS and performance-oriented managed WordPress — with centralised rewrite rules.
Do plugins break more often under Nginx?
Plugins that write .htaccess rules do not apply them automatically under Nginx. You must translate into server config or use managed WordPress hosting that does it for you, like Raidboxes.
Which stack for high-traffic sites?
Nginx as reverse proxy with PHP-FPM, Redis object cache and page cache via plugin or Varnish is the most common pattern. Apache alone with mod_php saturates faster under concurrency.
Can I keep Apache on a VPS?
Yes, especially with PHP-FPM rather than mod_php, and OPcache enabled. The issue is not the logo — it is process model, cache and fine tuning.
Before migrating to Nginx, list plugins that touch .htaccess. If there are five, budget translation time — or go managed.