Client Errors

Errors with a status code starting with 4 mean your site received the request but wouldn’t or couldn’t complete it: the page doesn’t exist, the visitor isn’t allowed to see it, or the request was too large, or too many requests arrived at once. Unlike server errors, they don’t mean your site is down, but they usually point to a setting or file you can change.

401 Unauthorized

A 401 Unauthorized error means the page requires a username and password, and the visitor didn’t enter one or entered the wrong one.

• Password protection: If htpasswd protection is enabled on your site or staging environment, visitors see a login prompt before the site loads. Enter the username and password set in MyKinsta, or turn off htpasswd protection if the site should be public.
• API requests: Tools and integrations that connect to your site through the WordPress REST API get a 401 if their credentials, such as an application password, are missing, wrong, or revoked. Check the credentials in the tool’s settings.

403 Forbidden

A 403 Forbidden error means the request was blocked on purpose. Several layers can block a request to your site, and each shows a different page, so the page you see is the quickest way to find the cause.

Identify what blocked the request

Open the page that shows the error and compare it with the list below. If a visitor reported the error, ask them for a screenshot.

Then follow the steps for that type of block below.

Blocked by an access rule in MyKinsta

If the page shows only a “403 Forbidden” heading, the request was blocked by your site’s access rules before it reached your site, so it doesn’t appear in your site’s logs.

1. In MyKinsta, go to Sites > sitename > Bot protection and go to the Top traffic report. Select the traffic type that was blocked to see the IP addresses, paths, user agents, and countries involved.
2. Check your Protection level. Stricter levels block automated traffic, which can include legitimate tools such as uptime monitors, payment webhooks, and plugin integrations. Enable Allow typical WordPress automations, or add an Allow exception for the tool. For more information, see Bot protection.
3. Check your bot protection Exceptions for a Block rule that matches the visitor’s IP address, path, user agent, or country.
4. Check whether the visitor’s IP address is listed in the Block IP Address tool.

If you’re testing with your own IP address, turn off any VPN or privacy relay, such as iCloud Private Relay, first. Otherwise, your site sees the relay’s IP address instead of yours, and an exception for your IP won’t match.

Blocked by the web server

If the page shows “nginx” under the heading, the web server refused to serve the file or folder requested. Search your site’s access.log for 403 to find the URL, then check:

• A folder without an index file: Visiting a folder that doesn’t contain an index.php or index.html file returns a 403 rather than listing the folder’s contents. Add an index file, or link to a specific file instead of the folder.

Blocked by Vulnerability protection

If the page shows Access Denied with an error code, Vulnerability protection blocked the request because it matched a rule for a known vulnerability in a plugin, theme, or WordPress version installed on your site.

This usually means part of your site is out of date. Some vulnerabilities affect common features, such as uploading files through a form, so a rule can block normal visitors as well as attackers until the affected plugin is updated.

1. In MyKinsta, go to Sites > sitename > Plugins and themes and filter the list by Vulnerable plugins. A vulnerable version is marked with an exclamation mark, and its version number is highlighted in red. For more information, see Manage Plugins and Themes.
2. Update the vulnerable plugins first, along with the plugin that handles the blocked page or feature. If you can’t tell which plugin is involved, update all your plugins, themes, and WordPress core.
3. Test the blocked page or action again.
4. To keep this from happening again, enable automatic updates.

Vulnerability protection can’t be turned off, and Allow exceptions in bot protection don’t override it. If the error continues after you’ve updated everything, contact Support and include the error code shown on the page.

Blocked by a security plugin or CDN

If the page is branded by a security plugin, such as Wordfence or Solid Security, or by a third-party CDN or firewall, that service blocked the request. Check its settings or logs for the blocked request, and add an exception there. If you use your own Cloudflare account, don’t enable Cloudflare’s WAF or bot protection features alongside Kinsta’s bot protection, because the two can block legitimate traffic.

Blocked by WordPress

WordPress shows its own message when a logged-in user’s role doesn’t allow an action, or when a security link has expired:

• “Sorry, you are not allowed to access this page”: The user’s role doesn’t have permission. Check the user’s role in Users in WordPress, or log in as an administrator.
• “The link you followed has expired”: The page was open too long or was loaded from cache. Reload the page and try again. If you see this when uploading, the file may also be too large; see 413 Request Entity Too Large.

When to contact Support

If you can’t find what’s blocking the request, contact Support with the URL, the time and timezone of the error, a screenshot of the error page, and the visitor’s IP address if you know it.

404 Not Found

A 404 Not Found error means the page or file requested doesn’t exist at that URL. A few 404s are normal, such as visitors mistyping a URL or bots requesting files your site doesn’t have. Look into them when real pages or files return 404s, or when 404s start after a change to your site.

Your site’s access.log records each 404 with the URL requested, so search it for 404 to see which URLs are affected.

• All posts and pages return 404s, but the homepage works: WordPress’s permalink settings need refreshing. In WordPress, go to Settings > Permalinks and click Save Changes without changing anything.
• After a migration, domain change, or environment push: Links and file paths may still point to the old domain or folder. Use the Search and Replace tool to update old URLs, and check that uploaded files were copied across.
• A file that exists returns a 404: The web server may not have permission to read it. Your site’s error.log shows open() "..." failed (13: Permission denied) with the file’s path. This often happens after uploading files over SFTP or deploying code. Check the file’s permissions in your SFTP client (most show them when you right-click a file and open its permissions or info) or over SSH with ls -l. Files should be set to 644 and folders to 755.
• A page or file was moved or deleted: Add a redirect from the old URL to the new one, so existing links and search results still work.
• A page you just published still shows a 404: The 404 may be cached. Clear your site’s cache and any CDN cache.

413 Request Entity Too Large

A 413 Request Entity Too Large error means a request, usually a file upload, was too large to accept. Your site has two upload limits, and which one a file goes over decides what you see:

• The web server’s limit (128 MB): Requests larger than 128 MB are rejected before they reach WordPress. Tools such as curl and API clients show the 413 error, but browser upload tools, such as the WordPress media uploader, usually show a general upload error instead. Your site’s error.log records the request as client intended to send too large body, followed by its size in bytes.
• Your plan’s PHP upload limit: The request reaches WordPress, but PHP drops the file, so there’s no 413. Instead, WordPress shows its own message, such as “exceeds the maximum upload size for this site” or The link you followed has expired.

Your plan’s PHP upload limit (upload_max_filesize and post_max_size) is:

• 128 MB: Single 125k visits and below, Single 65 GB bandwidth and below, WP 2, Launch, Launch Plus, Build, and Expand.
• 256 MB: Single 315k visits and above, Single 125 GB bandwidth and above, WP 5 and above, Scale, and Lead.
• Dedicated servers: The limit can be increased to 500 MB. Contact Support to change it.

If you need to upload files larger than your limit, use one of the options below.

• Upload large files another way: Upload large files, such as videos, backups, or import files, over SFTP instead of through the browser. For WordPress media, you can then add them to the Media Library with WP-CLI (wp media import).
• Reduce the file size: Compress images and videos, or split large import files into smaller ones.
• Large database imports: Use WP-CLI as described in Import MySQL Database.
• Third-party CDN: If you use another CDN or proxy, it may have a lower size limit than Kinsta. Check its upload limit.

429 Too Many Requests

A 429 Too Many Requests error means too many requests came from the same source in a short time, so your site’s web server temporarily limited them. Requests over the limit are rejected until the rate drops, and other visitors aren’t affected.

Your site’s error.log records each limited request as limiting requests, excess: ... by zone "phpzone".

• Bots and scrapers: Automated traffic crawling many pages quickly is the most common cause. Use the Top traffic report in Bot protection to find the source, then block it or raise your protection level.
• Plugins and integrations: Tools that sync, import, or check your site can send bursts of requests, for example to admin-ajax.php or the WordPress REST API. Reduce how often they run, or set them to send requests in smaller batches.
• Load testing: Tools that simulate heavy traffic from one source are rate-limited quickly. Load testing isn’t allowed on Kinsta; for more information, see our Terms of Service.

If legitimate traffic is being limited, contact Support with the time of the errors and the IP address or tool involved.