Table of Contents
Every self-hosted WordPress developer eventually goes through the same rite of passage. You log into your dashboard, navigate to the Permalinks setting, change your URL structure from a messy date format to a clean /post-name/ style, and hit save. You navigate back to your home page, click an article link, and the screen goes completely white: 500 Internal Server Error. The terminal ghost has struck again.
The 500 error is Apache’s way of saying, “Something broke inside my configuration engine, but Iβm too proud to show you the error message.” In 99% of cases on a GCP instance, this is caused by a broken interaction between your WordPress core system, your file system permissions, and your .htaccess directives. Let’s fix the plumbing permanently.
1. The Root Cause: AllowOverride Desolation
When you spin up a fresh, standard Linux VM with an Apache stack, the default global security profile is set to maximum restriction. Inside the master configuration file, Apache specifies that local configuration overrides are completely disabled:
Apache
AllowOverride None
When WordPress attempts to rewrite your URLs, it writes specialized rules inside a hidden local file called .htaccess. If Apache is configured to ignore local overrides, it encounters a conflict of architectural authority, panics, and shuts down the entire request cycle with a 500 error status.
2. The Surgical Nano Intervention
To banish this ghost, you must SSH directly into your GCP instance and claim root directory permissions to modify Apache’s core rules behavior.
Run the following command to target your primary site profile setup:
Bash
sudo nano /etc/apache2/sites-available/000-default.conf
Scroll down until you locate your primary directory block <Directory /var/www/html>. Change the restrictive security line to allow unrestricted structural overrides:
Apache
AllowOverride All
Save the changes using the Ctrl + O write-out command, exit the nano editor with Ctrl + X, and force Apache to reload its structural system mappings:
Bash
sudo systemctl restart apache2
3. Rectifying File Ownership Demands
If your server still refuses to comply, your file permissions are out of alignment. If the core Linux system user account (www-data) does not own the physical .htaccess file, it cannot read the rules you are trying to execute.
Forcefully realign file ownership across your entire WordPress infrastructure using this direct execution command:
Bash
sudo chown -R www-data:www-data /var/www/html/
This explicitly tells the Linux kernel that Apache has full, unhindered authority to read, write, and execute files within your web directory. The 500 error vanishes, your clean URLs function perfectly, and you can finally close your terminal and sleep in peace.