ERROR · 01 · VERIFIED 2026-10allwpcare.com/errors/500-internal-server-error/
Errors / 500-internal-server-error

500 Internal Server Error in WordPress

The web server failed before WordPress could answer. Read the server error log, then check .htaccess, file permissions, PHP settings and the PHP handler.

The message you see
1−Internal Server Error
2−The server encountered an internal error or misconfiguration and was unable to complete your request.
Last verified Oct 2026Tested with WordPress 7.1Applies to WordPress 7.1 (tested on Apache) · PHP 7.4+
Written and tested by AllWPCare Team · First published Oct 17, 2026

Why it happens

  • The .htaccess file in the WordPress root has a line Apache does not accept, often after a plugin or a pasted snippet edited it.
  • A PHP setting in .htaccess, such as php_value or php_flag, is used on a server where PHP does not run as an Apache module.
  • File or folder permissions are wrong, so the server cannot read the files it needs.
  • The PHP process crashed or hit a hosting limit, for example memory, processes or execution time.
  • The PHP version or handler selected for the site does not match the code, after a host change.
  • A plugin or theme caused a fatal error. WordPress usually catches that and shows its own message, but not when the error happens before WordPress loads.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

FIX 01

Find out who is answering

  1. Compare the page with the WordPress critical error message. "There has been a critical error on this website" is also sent with a 500 status, but it comes from WordPress. If you see that, use the critical error guide.
  2. A plain page headed "Internal Server Error" with no styling comes from the web server. WordPress never ran. On Apache it ends with a line like Apache/2.4.x Server at example.com Port 443. Many hosts turn that footer off, so its absence does not mean the page is from nginx or WordPress. Nginx shows a short "500 Internal Server Error" page that names nginx.
  3. If the page is from the server, the reason is in the server's error log. The page tells you nothing more.
FIX 02

Read the server error log

  1. In your hosting control panel, look for Logs, Error log or Metrics. Many hosts also let you download error_log over SFTP.
  2. On a server you manage, Apache logs are often in /var/log/apache2/error.log or /var/log/httpd/error_log, and nginx logs in /var/log/nginx/error.log. In Docker, docker compose logs shows the same lines.
  3. Find the line with the time you loaded the page. A broken .htaccess gives a line like /var/www/html/.htaccess: Invalid command 'BogusDirective', perhaps misspelled or defined by a module not included in the server configuration. I produced exactly that line on Apache 2.4 by adding one bad line to the file.
  4. The text after the file name is the reason. Use it in the next steps.
FIX 03

Test whether .htaccess is the cause

  1. Connect by SFTP, turn on hidden files, and find .htaccess in the folder that contains wp-config.php.
  2. Download a copy, then rename the file on the server to .htaccess.off.
  3. Reload the site. On my test site a bad .htaccess made every URL return 500, including /wp-login.php and /wp-admin/, and the site returned to normal as soon as the file was out of the way.
  4. If the site loads, the file was the cause. Pretty-permalink pages may now return 404, which is expected until the file is rebuilt.
  5. Moving .htaccess aside also drops any security, redirect or HTTPS rules your host or a plugin kept in it, such as deny rules or blocks on wp-config.php and xmlrpc.php. Put the copy back, or rebuild it, rather than leaving the site without it.
FIX 04

Rebuild .htaccess

  1. Log in to /wp-admin/, open Settings → Permalinks, and click Save Changes. WordPress writes a fresh .htaccess with its own rules. I checked this on a test site with no .htaccess: the file appeared and posts worked again.
  2. If WordPress says "You should update your .htaccess file now", it cannot write the file. Create .htaccess yourself with the standard WordPress block, shown below, and save it in the WordPress root.
  3. With WP-CLI, wp rewrite flush --hard only writes the file if apache_modules: - mod_rewrite is set in wp-cli.yml. Without that, it prints a warning and does nothing to the file.
  4. If your old file held rules from a security, redirect or caching plugin, re-save that plugin's settings. Do not paste the old file back until you have found the bad line.
FIX 05

Check file permissions and ownership

  1. The WordPress hardening guide recommends 755 for folders and 644 for files, and 400 or 440 for wp-config.php. Many hosts use 640 or 600 for it, which is common practice. Avoid 777.
  2. Wrong ownership is a more usual cause than wrong mode. Files must be owned by the user your PHP process runs as. If you recently restored files as another user, run ls -l to see the owner and ask your host for the right one. Mode 755 will not let a different PHP user write to wp-content/uploads.
  3. If the modes really are wrong, run pwd over SSH first and confirm the folder contains wp-config.php. Running the next commands from the wrong directory changes files you did not mean to touch.
  4. Then run find . -type d -exec chmod 755 {} + and find . -type f -exec chmod 644 {} +. This also strips executable bits from any scripts.
  5. Afterwards re-tighten the config file with chmod 640 wp-config.php (or 600, or the 400/440 the hardening guide gives), because the blanket command set it to 644.
  6. I did not reproduce a permission failure for this page. The log line for one usually says Permission denied or File not readable.
FIX 06

Check PHP settings, version and handler

  1. If the log names php_value or php_flag as an invalid command, remove those lines from .htaccess. On hosts where PHP runs as FastCGI, set the same values in .user.ini or php.ini instead.
  2. In the hosting panel, check the PHP version selected for this site. If the error began when the version changed, switch back, then update plugins and themes before trying again.
  3. If the log mentions memory or timeouts, see the memory limit guide, or ask your host whether the account hit a process or resource limit at that time.
FIX 07

Look for a plugin or theme

  1. With WP-CLI, first note the active plugins with wp plugin list --status=active so you can restore the list. Then run wp plugin deactivate --all --skip-plugins and reload the site.
  2. Without WP-CLI, rename single plugin folders over SFTP, one at a time, to find the cause. Renaming the whole wp-content/plugins folder to plugins.off also works for a quick test, but do not open Settings or Plugins in wp-admin while it is renamed. The Plugins screen permanently deactivates every active plugin whose file it cannot find, and you would have to reactivate each one.
  3. If you still see 500, try a default theme with wp theme activate twentytwentyfive --skip-themes.

A 500 status means the server could not finish the request. It is a general failure code, not one cause. The useful question is who produced it: the web server before WordPress started, or WordPress itself.

If the page says only "Internal Server Error", the server answered and WordPress did not run. The reason is in a log file, never on the page. Your content is not touched by this error.

A plain white page. The heading says Internal Server Error. Below it: The server encountered an internal error or misconfiguration and was unable to complete your request. Then: please contact the server administrator, and more information about this error may be available in the server error log. A small footer line reads Apache/2.4.69 (Debian) Server at localhost Port 8902.
The page Apache 2.4 sent after I added one invalid line to .htaccess. The server error log named the line. The page itself does not.

The same status can come from two places, and the fix depends on which one.

Five stacked steps. The web server gets the request. It can fail first, on a bad .htaccess line, wrong permissions or a crashed PHP process, and WordPress never runs. If WordPress starts and a PHP fatal error happens, it usually shows the critical error message, or a blank page if the fatal error handler is off. The server log explains the first case and the debug log the second.
A 500 from the web server comes before WordPress. A 500 from WordPress usually comes with its own message, or a blank page if the fatal error handler is off.

The standard .htaccess block#

If you rebuild the file by hand, this is the block WordPress wrote on my test site when I saved the permalink settings. It is for a single-site install with pretty permalinks.

.htaccess
# BEGIN WordPress# The directives (lines) between "BEGIN WordPress" and "END WordPress" are# dynamically generated, and should only be modified via WordPress filters.# Any changes to the directives between these markers will be overwritten.<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress

Lines outside the BEGIN and END markers belong to you or to other plugins. WordPress leaves them alone when it rewrites its block, and WordPress overwrites everything inside the markers. A bad line outside the markers is a common cause of this error.

If you have lost or damaged the WordPress block, the .htaccess generator builds a file that keeps it intact.

Nginx has no .htaccess#

On nginx, .htaccess does nothing, so a 500 never comes from it. Look at the nginx error log and at the PHP-FPM log, which is a separate file. A 502 or 504 from nginx points at PHP-FPM being down or slow, not at WordPress. I tested only the Apache case on this page.

The order to work in#

  1. Decide whether the page came from the server or from WordPress.
  2. Read the server error log for the matching time.
  3. Move .htaccess aside if the log or the timing points at it.
  4. Check permissions, PHP version and plugins only if the log does not already name the cause. If WordPress itself catches a PHP fatal error, you get the critical error message or a white screen, not this page.

After it is fixed#

Check the home page, a post, a page, /wp-login.php and a form if the site has one. If you rebuilt .htaccess, confirm that redirects and security rules from your plugins are back. A pretty-permalink 404 after the repair is covered in posts return 404.

If a plugin changed settings along the way, see how to find and undo changed settings.

Sources

  1. Apache HTTP Server: .htaccess files · What .htaccess can hold, and that a bad directive stops the request
  2. Apache HTTP Server: log files · Where the error log is and what a line contains
  3. MDN: 500 Internal Server Error · What the 500 status means
  4. WordPress: file permissions · Folders 755 or 750, files 644 or 640, and the stricter modes for wp-config.php
  5. WordPress: Apache .htaccess for WordPress · The standard WordPress rewrite block
Newsletter

One email when something breaks or changes.

New plugins and re-tested guides, about twice a month. Never a sales pitch.