400 errors hinder search engine indexing, negatively impact user experience, waste crawl budget, and dilute page rank from backlinks, undermining website authority and search performance.
Here’s everything you need to know:
What is a 400 Error?
A 400 Bad Request error is an HTTP status code that indicates the request sent by the client (typically a web browser) to the server is malformed or incorrect in some way, such that the server cannot understand or process it.
The issue is generally client-side, meaning the problem resides with the requester, not the server.
Why 400 Errors Are Bad for SEO
When it comes to SEO (Search Engine Optimization), encountering a 400 Bad Request error can have negative implications for your website’s search performance and user experience. Here’s how:
1. Crawlability and Indexing
Search engine bots like Googlebot crawl the web to index and understand the content of websites. If they encounter a 400 error when trying to access a page, they won’t be able to index that page.
Frequent 400 errors can indicate poor website health, and over time, this might reduce the frequency with which bots crawl your site.
2. User Experience (UX)
If actual users encounter 400 errors when trying to visit a page on your site, it negatively affects their experience.
Poor UX can indirectly impact SEO, as search engines aim to provide users with the best possible results. Such errors can influence metrics like bounce rate and time spent on site.
3. Loss of Authority
If the URL that’s throwing a 400 error has valuable backlinks pointing to it, the authority from those backlinks might be wasted. This can harm your website’s overall domain authority and rankings.
4. Dilution of Crawl Budget
Websites have a limited “crawl budget,” which is the number of pages search engines will crawl in a given time frame. If bots waste time on URLs that return 400 errors, they might not get to other, more important pages.
5. Potential for Decreased Trust
Frequent errors can reduce trust in the eyes of search engines. Search engines want to serve reliable and accessible content to their users. A website that frequently returns errors might be seen as less reliable.
7 Common Causes of 400 Errors
There are several reasons why a 400 Bad Request error might occur:
Invalid URL
If the URL structure is incorrect or contains invalid characters.
Suppose you own a website that sells books, and each book has its own dedicated page with a URL structure like this:
https://www.examplebookstore.com/book/[BOOK_ID]A valid URL might look like:
https://www.examplebookstore.com/book/12345However, someone tries to access a book using a malformed URL:
https://www.examplebookstore.com/book/12345??invalid_paramThe above URL contains “??” which is not a standard URL character sequence. The server doesn’t recognize or understand this malformed structure, leading it to return a 400 Bad Request error.
To fix this, the user or system generating the URL should ensure that URLs are formatted correctly, using proper character sequences and following the expected structure. In this case, eliminating the “??invalid_param” would likely resolve the error.
Cookie Size
If a cookie associated with the website has become too large or corrupted, it might trigger a 400 error.
Scenario
Imagine you have an e-commerce website where users can add products to their wishlist.
Every time a user adds a product to their wishlist, this action gets stored in a cookie to remember their preferences for future visits.
Over time, a regular customer, Jane, has added hundreds of items to her wishlist. The data stored in her wishlist cookie grows significantly, surpassing the typical size limit for cookies (which is generally around 4 KB per cookie).
The next time Jane visits the website, her browser tries to send the oversized wishlist cookie back to the server.
The server, seeing a cookie that’s too large to process, responds with a 400 Bad Request error, indicating the request headers (which include cookies) are too large.
How to Fix
Jane can clear her browser cookies for mystore.com, which would remove the oversized wishlist cookie and allow her to access the site again.
On the website’s end, developers should implement a mechanism to prevent cookies from becoming too large, perhaps by storing only a limited number of items in the wishlist cookie or using server-side storage for such data.
Request Header Issues
Headers that are too large or improperly formatted can result in a bad request.
Scenario
Alex is a developer building an application that integrates with a third-party API. To retrieve data, the API requires an authentication token to be passed in the request header. The expected header format is:
Authorization: Bearer YOUR_TOKEN_HEREWhile developing, Alex mistakenly configured the application to send the token in an incorrect format:
Authorization: Bearer-YOUR_TOKEN_HERENotice the misplaced hyphen instead of a space after “Bearer.”
When Alex’s application tries to fetch data, the server recognizes the improperly formatted header and responds with a 400 Bad Request error because it cannot process the malformed authorization header.
How to Fix
Alex needs to correct the request header by ensuring it follows the proper format, changing it to:
Authorization: Bearer YOUR_TOKEN_HEREFor future prevention, automated tests could be set up to verify that the request headers are correctly formatted before sending them to the API.
This way, any deviations from the expected format can be caught early in the development process.
File Size Too Large
When the client sends a request with a file size that exceeds the server’s limit.
Scenario
Liam runs a community website where users can upload their photography. The website has a set limit of 5MB per image upload to manage storage and ensure speedy page loads for visitors.
An amateur photographer, Maria recently went on a trip and captured high-resolution photos. Excited to share her work, she attempts to upload a detailed 15MB photograph.
Upon selecting the image and hitting the ‘Upload’ button, the website quickly returns a 400 Bad Request error. The message accompanying the error reads: “File size exceeds the 5MB limit. Please compress or choose a smaller file.”
How to Fix
Maria can use photo editing software or online tools to compress or resize her image to meet the website’s file size requirement.
On the website’s side, Liam could consider implementing a more user-friendly alert before the upload process starts, warning users if their files exceed the set limit.
This proactive approach would enhance user experience by preventing the error from occurring in the first place.
Client-Side Caching
Corrupted or outdated cached data in the browser can trigger this error.
Scenario
Sam frequently visits an online forum. Over time, his browser caches various elements of the website, such as stylesheets, scripts, and other assets, to make subsequent visits load faster.
One day, the developers deployed a significant update, changing some core elements of the site. However, Sam’s browser still retains the old cached version.
The next time Sam tries to post a comment on a thread, his browser uses the outdated cached scripts. The old scripts send data in a format that the updated server no longer understands. Consequently, the server returns a 400 Bad Request error, indicating there’s something wrong with the data it received.
How to Fix
Sam can clear his browser cache, forcing his browser to fetch the latest version of all resources from chatplace.com on his next visit, aligning with the server’s recent updates.
The developers can implement versioning techniques for their assets or use cache-control headers to specify how long assets should be cached.
This would signal browsers to fetch newer versions when significant updates are made, reducing the potential for such errors.
Issues with Data Payloads
If you send data in the body of the request (e.g., with a POST or PUT request), malformed data or incorrect formatting can lead to a 400 error.
Scenario
Riley has built a web application for online reservations.
Users can reserve seats for events by filling out a form with details like their name, email, and the number of seats they want to reserve.
Emma, a site user, fills out the reservation form for a concert. However, due to a minor bug in the website’s code, when she selects “5” seats, the site erroneously sends the data as “seats”: “five” instead of “seats”: 5.
Upon submission, the server expects a numeric value for the number of seats. However, because it received the word “five” instead of the number 5, it’s unable to process the request.
It returns a 400 Bad Request error, signaling an issue with the data sent.
How to Fix
Riley, the developer, needs to investigate the form’s code and correct the issue, ensuring that numeric values are sent as numbers and not text representations.
Implementing input validation both on the client and server sides can prevent such issues. If the client-side code detects an inconsistency in the data format, it can alert the user before sending the request.
Similarly, server-side validation can give more descriptive error messages, helping troubleshoot quicker.
Rate Limiting
If a client sends too many requests in a given time frame, some servers will respond with a 400 error.
Scenario
Carlos is developing a weather app that pulls data. The API provides real-time weather data, but to prevent abuse and ensure fair use, each user has a rate limit of 100 requests per hour.
Eager to see his app in action, Carlos sets up his application to fetch updates every 10 seconds to test its performance under rapid data refresh scenarios. After 16 minutes, his app has made 96 requests. By the 17th minute, his app exceeds the 100-request limit.
When the app tries to make its 101st request within the hour, it responds with a 400 Bad Request error.
The response body contains a message: “Rate limit exceeded: You’ve made over 100 requests in the last hour. Please wait before making additional requests.”
How to Fix
Carlos should adjust the frequency of his requests to ensure they stay within the API’s rate limits. If real-time data isn’t critical, he could consider fetching data less frequently.
Implementing a caching mechanism can help reduce the number of direct calls to the API. The app can serve user requests without constantly hitting the external API by storing and reusing previously fetched data for a certain period.
Carlos could also implement error handling in his app to recognize rate-limiting errors and inform users to try again later or adjust the app’s behavior accordingly.
How to Find 400 Errors with Screaming Frog
Run a crawl with Screaming Frog and look under “Status Code” to find all instances of 400 errors:
How to Fix 400 Errors
Fixing 400 Bad Request errors involves identifying the root cause and then addressing it. Here’s a step-by-step guide:
1. Check URL Structure
Ensure URLs are correctly formatted without invalid characters or structures.
2. Review Request Headers
Ensure headers are properly formatted. If using an API, double-check the required headers.
3. Clear Cookies
Some 400 errors arise from corrupted or oversized cookies. Clearing your browser’s cookies or using a different browser can help determine if this is the issue.
4. Inspect Data Payloads
If sending data (like with a POST request), ensure the data is formatted correctly and adheres to expected input formats.
5. Reduce File Size
If a request includes a file upload, ensure it doesn’t exceed server size limits.
6. Update Outdated Links
If the error arises from outdated or changed links, update them to point to the correct URLs.
7. Reset Client-Side Cache
Clear the browser cache to resolve potential issues with cached data.
8. Server Configuration
On the server side, check for any misconfigurations or rate-limiting rules that could be causing the error.
9. Logs and Monitoring
Review server logs to gain insights into the specifics of the error. Tools like Google Search Console can also alert you to such issues on a website.
10. Reach Out
If accessing a third-party site or service, contact their support or IT team for assistance if the error persists.
Once the root cause is identified and addressed, ensure that the problematic request or URL is tested multiple times to confirm that the issue is fully resolved.
Regular monitoring can also help catch and fix such errors promptly.
Conclusion on 400 Errors
While a sporadic 400 error might not be catastrophic, recurrent issues can negatively impact SEO and user experience.
It’s crucial to monitor and address these errors for optimal website health actively.
