There's nothing worse than visiting your own website and seeing an error page instead of your content. HTTP errors are inevitable — every website encounters them eventually. The difference between a minor hiccup and a prolonged outage is knowing how to diagnose and fix them quickly.
This guide covers the most common website errors, what causes them, and exactly how to fix each one.
Understanding HTTP Status Codes
Before diving into specific errors, it helps to understand the numbering system:
- 2xx — Success (200 OK is what you want)
- 3xx — Redirects (the page moved somewhere else)
- 4xx — Client errors (the visitor did something wrong, or the page doesn't exist)
- 5xx — Server errors (something broke on your end)
The 4xx and 5xx errors are the ones that need your attention.
404 Not Found
What it means: The server can't find the page the visitor requested.
Common causes:
- The page was deleted or moved without a redirect
- A typo in the URL
- Broken internal or external links
- Permalink structure changed (common in WordPress)
How to fix it:
Check the URL — Is it spelled correctly? Case matters on some servers.
Set up redirects for moved pages:
# Nginx redirect
location /old-page {
return 301 /new-page;
}
# Apache .htaccess redirect
Redirect 301 /old-page /new-page
WordPress permalink fix — Go to Settings → Permalinks and click "Save Changes" (even without changing anything). This regenerates your rewrite rules.
Create a custom 404 page — Give visitors a helpful page with search and navigation instead of a generic error.
Prevention: Use a broken link checker (Screaming Frog, or the "Broken Link Checker" WordPress plugin) to catch 404s before visitors do.
500 Internal Server Error
What it means: Something went wrong on the server, but the server can't be more specific about what.
Common causes:
- PHP errors or syntax mistakes
- Corrupted
.htaccessfile - PHP memory limit exceeded
- Incompatible plugin or theme (WordPress)
- File permission issues
- Faulty server configuration
How to fix it:
- Check error logs — This is always step one:
# Nginx error log
sudo tail -50 /var/log/nginx/error.log
# Apache error log
sudo tail -50 /var/log/apache2/error.log
# PHP error log
sudo tail -50 /var/log/php-fpm/error.log
# WordPress debug log (if enabled)
cat wp-content/debug.log
- Enable WordPress debugging to see the actual error:
// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
- Rename .htaccess to rule it out:
mv .htaccess .htaccess.backup
If the site works, regenerate it from WordPress Settings → Permalinks.
- Disable all plugins to find the culprit:
# Rename plugins folder
mv wp-content/plugins wp-content/plugins_disabled
If the site works, re-enable plugins one by one to find the problematic one.
- Increase PHP memory:
// wp-config.php
define('WP_MEMORY_LIMIT', '256M');
Or in php.ini:
memory_limit = 256M
- Fix file permissions:
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
502 Bad Gateway
What it means: The web server (Nginx/Apache) received an invalid response from an upstream server (PHP-FPM, Node.js, etc.).
Common causes:
- PHP-FPM crashed or isn't running
- Node.js/application process crashed
- Timeout between web server and application
- Server ran out of memory
How to fix it:
- Check if your application process is running:
# PHP-FPM
sudo systemctl status php-fpm
sudo systemctl restart php-fpm
# Node.js with PM2
pm2 status
pm2 restart all
# Check if process is listening
sudo ss -tlnp | grep :9000 # PHP-FPM default port
- Check server memory:
free -h
# If memory is full, identify the culprit
top -o %MEM
- Increase timeout values in Nginx:
location ~ \.php$ {
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_connect_timeout 300;
# ... other fastcgi settings
}
- Check PHP-FPM logs:
sudo tail -50 /var/log/php-fpm/www-error.log
503 Service Unavailable
What it means: The server is temporarily unable to handle requests — usually due to overload or maintenance.
Common causes:
- Server is overloaded with traffic
- Application is in maintenance mode
- Rate limiting kicked in
- Server resources (CPU/RAM) exhausted
- DDoS attack
How to fix it:
- Check server load:
uptime # Check load averages
htop # Real-time process monitoring
If load averages exceed your CPU core count, the server is overloaded.
- Check if maintenance mode is active:
# WordPress creates a .maintenance file during updates
ls -la /var/www/html/.maintenance
# Delete it if the update is done
rm /var/www/html/.maintenance
- Restart services:
sudo systemctl restart nginx
sudo systemctl restart php-fpm
# Or for the entire web stack
sudo systemctl restart nginx php-fpm mysql
- If under heavy traffic, enable caching:
# Install and enable FastCGI cache in Nginx
# Or use a WordPress caching plugin (WP Super Cache, W3 Total Cache)
- Check for DDoS — Look at access logs for unusual patterns:
# Top IPs hitting your server
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
If one IP is making thousands of requests, block it:
sudo ufw deny from 123.456.789.0
403 Forbidden
What it means: The server understood the request but refuses to authorize it.
Common causes:
- Incorrect file/directory permissions
- IP blocked by firewall or security plugin
- Missing index file
.htaccessrules blocking access- Directory listing disabled (which is good) but no index file exists
How to fix it:
- Check permissions:
ls -la /var/www/html/
# Directories should be 755, files should be 644
# Owner should be the web server user (www-data, nginx, etc.)
- Check if your IP is blocked:
# Check firewall
sudo ufw status
# Check fail2ban
sudo fail2ban-client status
- Ensure an index file exists in the directory:
ls /var/www/html/index.*
# Should see index.html, index.php, etc.
408 Request Timeout
What it means: The server timed out waiting for the client's request.
Common causes:
- Slow internet connection
- Large file upload exceeding timeout
- Server timeout set too low
How to fix it:
Increase timeout values:
# Nginx
client_body_timeout 120;
client_header_timeout 120;
send_timeout 120;
For large file uploads:
client_max_body_size 100M;
// php.ini
upload_max_filesize = 100M
post_max_size = 100M
max_execution_time = 300
General Troubleshooting Workflow
When you encounter any error, follow this systematic approach:
- Read the error log — 90% of problems are explained in the logs
- Check what changed — Did you update something? Install a plugin? Change config?
- Reproduce the error — Is it every page or just one? Every visitor or just you?
- Google the specific error message — Include your stack (Nginx, PHP, WordPress, etc.)
- Undo the last change — If the error started after a change, revert it
- Restart services — Sometimes the simplest fix works
Monitoring to Catch Errors Early
Don't wait for visitors to report errors. Set up monitoring:
- UptimeRobot (free) — Alerts you when your site goes down
- Google Search Console — Reports crawl errors Google encounters
- Error log monitoring — Set up alerts for 500-level errors in your logs
Keep Your Site Running Smoothly
Website errors are inevitable, but prolonged downtime isn't. Understanding what each error means and having a troubleshooting playbook ready means you can fix issues in minutes instead of hours.
At DeployBase, our hosting infrastructure is designed to minimize errors with optimized server configurations, automatic resource scaling, and proactive monitoring. When issues do occur, our 24/7 support team is ready to help you get back online fast. We also provide detailed error logs and server monitoring dashboards so you always know what's happening with your site.
Get reliable hosting with DeployBase → — because your website should just work.




