A 500 Internal Server Error on a WordPress site running under aaPanel almost never comes with a useful message on the page itself — the real cause is sitting in a log file aaPanel already collects for you. Before changing any settings, read that log first; it tells you which of the four common causes you're actually dealing with instead of making you guess.

Symptoms

  • The front end, wp-admin, or both show "500 Internal Server Error" with no further detail.
  • The error appeared right after installing/updating a plugin or theme, restoring a backup, or uploading files via FTP/SFTP.
  • Some pages load fine while others (often wp-admin specifically, or one specific plugin's page) return the 500.
  • The error is intermittent — works, then fails, then works again — which usually points to a resource limit rather than a hard PHP fatal error.

Likely causes, in order of how often they actually happen

  1. A plugin or theme is throwing a PHP fatal error. This is by far the most common cause — a plugin update that isn't compatible with your PHP version, a theme function that references something that no longer exists, or two plugins conflicting.
  2. PHP's memory_limit is too low for what the site is trying to do. This shows up especially during image-heavy page builds, large imports, or after adding a plugin that does more processing per request.
  3. File permissions are wrong after an upload, migration, or restore. PHP-FPM running as the wrong user, or files uploaded with overly restrictive or overly open permissions, can make Nginx/PHP refuse to execute them.
  4. An Nginx configuration issue in the site's config block (aaPanel's equivalent of a broken .htaccess) — usually introduced by a rewrite rule pasted in from a plugin's setup instructions that assumes an Apache environment.

Fix it: lowest-risk steps first

Step 1 — Read the actual error, don't guess

In aaPanel, go to Website → your site → Log, which shows the Nginx access and error log for that domain directly in the panel. Look at the most recent entries in the error log around the time the 500 occurred — Nginx will usually name the specific issue (upstream error, config problem) even when WordPress itself doesn't.

For PHP-level fatal errors, check the PHP-FPM error log. In aaPanel this is under App Store → PHP (your active version) → Settings → Error Log, or directly at a path like /www/server/php/[version]/var/log/php-fpm.log. This log is where a fatal error from a specific plugin file will actually name the file and line number.

Also check /www/wwwlogs/ directly if you prefer file access over the panel UI — aaPanel stores each site's Nginx access and error logs there, named after the domain.

Reading these two logs takes under a minute and tells you immediately whether you're dealing with a PHP fatal error (go to Step 4) or something else.

Step 2 — Rule out a memory limit issue

If the PHP-FPM log mentions "Allowed memory size … exhausted," this is your cause. In aaPanel, go to App Store → PHP (your version) → Settings → php.ini, find memory_limit, and raise it — from the WordPress-standard 128M to 256M is a reasonable first step. Save and restart PHP-FPM for the change to apply (aaPanel prompts for this automatically after editing php.ini).

Don't jump straight to 512M or higher without evidence it's needed — a memory limit that's much higher than the site actually uses just delays the point at which a genuinely runaway process (like cause #1) gets killed, making the real problem harder to diagnose later.

Step 3 — Check file and folder permissions

If the 500 started right after an FTP upload, SFTP transfer, or a backup restore, permissions are the likely cause. In aaPanel, go to Website → your site → Permissions, or use the file manager's permission dialog on the site's root folder. WordPress's standard-safe values are 755 for directories and 644 for files, owned by the same user aaPanel's PHP-FPM pool runs as (commonly www). You can apply this recursively from the file manager's right-click menu on the site root — do this only after confirming permissions are actually the issue from Step 1's logs, since a recursive permission change on a large media library takes time and isn't instant to undo.

Step 4 — Isolate the plugin or theme causing the fatal error

If Step 1's PHP-FPM log names a specific plugin file, that plugin is your answer — deactivate it from Website → your site → wp-config access, or directly rename its folder via aaPanel's file manager under wp-content/plugins/ (adding -disabled to the folder name deactivates it without needing wp-admin access, which matters if wp-admin itself is the page returning the 500).

If the log doesn't name a specific file, isolate manually: rename the entire wp-content/plugins folder to something like plugins-test, then rename it back to plugins (this deactivates everything at once), confirm the site loads, then reactivate plugins one at a time from wp-admin until the 500 returns — the last plugin you activated is the cause.

Step 5 — Check the site's Nginx configuration for a bad rewrite rule

If none of the above resolved it, and the error log points at the Nginx config rather than PHP, go to Website → your site → Config to view the raw Nginx configuration aaPanel generates for that domain. Look for anything manually pasted in — most commonly a rewrite block copied from a plugin's Apache .htaccess instructions that doesn't translate directly to Nginx syntax. Comment out any custom block you don't recognize, save, and reload the config.

Verify the fix

  1. Load the front end and wp-admin in a private/incognito window and confirm both return normally with no 500.
  2. Recheck the Nginx error log and PHP-FPM log under Website → Log to confirm no new errors are appearing on fresh page loads.
  3. If you deactivated a plugin, confirm the specific feature it provided is genuinely broken without it (not just the 500) before deciding whether to remove it or find an updated/alternative version.

If you need to roll back

If a permissions change made things worse (e.g., the site now shows a different error like a blank screen or 403 instead), reset permissions using the same 755/644 standard rather than trying to remember the previous exact values — this is the safe default aaPanel and WordPress both expect. If a config edit under Step 5 broke things further, aaPanel keeps the previous config accessible in the same Config tab's history, or you can simply remove the custom block you added and reload. For anything more serious, restore from the backup you took before starting.

Related fixes

FAQ

Why does aaPanel show a 500 error with no detail on the page itself?

WordPress and PHP intentionally don't display fatal error detail on a live site by default — that's a security setting, not a bug. The detail always exists, it's just written to the server-side logs (PHP-FPM error log and Nginx error log) rather than shown to visitors. Reading those logs is the fastest way to actually diagnose the error rather than guessing.

Should I enable WP_DEBUG to see the error instead of checking logs?

You can, and it will show the same PHP fatal error directly on the page — but on a live site this also exposes file paths and error detail to any visitor who happens to hit the broken page while it's on, which is a bigger exposure than checking the log file directly in aaPanel. Use WP_DEBUG on a staging copy, or enable it only briefly and turn it back off immediately after you've seen the error.

Could this be a hosting-level resource limit rather than WordPress itself?

Yes — if the 500 coincides with high CPU or RAM usage shown in aaPanel's main dashboard (not just within the site), the server itself may be hitting its resource ceiling rather than this being a WordPress-specific issue. Check Home in aaPanel for overall server load before assuming the cause is inside WordPress.