HTTP Response Status Codes Explained

HTTP Status Codes

Any web server will issue HTTP status codes in response to a client’s request. This list shows codes from IETF Request for Comments (RFCs) and some additional commonly used codes. The first digit of the HTTP status code specifies one of five standard classes of responses.

1xx Informational

1xx status codes offer a temporary response. They’re made up of just the Status-Line and they end with an empty line. There’s no need for headers with this kind of status code. Because HTTP/1.0 doesn’t offer definitions for any 1xx status codes, servers mustn’t send a 1xx response to an HTTP/1.0 client, unless it’s for investigational purposes. A client needs to be ready to handle at least one 1xx status response before a regular response, even if the client doesn’t expect to receive a 100 continue status message. A user agent can safely ignore a 1xx status response if it wasn’t one that was expected. Proxies have to forward 1xx responses, except in the case of a closed connection between client and proxy, or except when the proxy itself produced the request to generate the 1xx response. (For instance, if a proxy includes an “Expect: 100-continue” field to the forwarded request, then it doesn’t need to forward the related 100 (Continue) response(s).)

100 Continue

This status code means that the server has received the request headers and that the client should carry on and send the request body (when the request is one for which a body needs to be included; like with a POST request for instance). With a request body that’s large, it’s not efficient to send it to a server after a request has been rejected already because the headers aren’t appropriate. It’s possible to ask the server to check whether the request will be accepted based solely on its headers by sending Expect: 100-continue as a header in its initial request. It will carry on if a 100 Continue status code is received in respons or it will stop if a 417 Expectation Failed response is received.

101 Switching Protocols

This tells us that the server has been asked to change protocols and it’s confirming that it will do that. It comprehends the client’s request and signals that it’s willing to abide by it, using the Upgrade message header field to change the application protocol in use on this connection. The server will change protocols to those defined by the response’s Upgrade header field right after it encounters the empty line which ends the 101 Switching Protocols response. The protocol should only be changed when it’s beneficial to do this. For instance, changing to a newer version of HTTP from older ones is beneficial, and changing to a synchronous, real-time protocol could be of benefit when resources that use such features need to be delivered.

102 Processing (WebDAV)

The 102 Processing code is an interim response that’s used to let the client know that the server has accepted the request but hasn’t yet fulfilled it. It should only be issued when there is a reasonable expectation that processing is going to take a while. When the server takes more than 20 seconds to run through a request, it will issue a 102 (Processing) response, and it will send a final response when the request has been completed. Methods can take a while to process, particularly those that support the Depth header. In these instances, the client may suspend the connection while it’s waiting for the response to come back, but if it issues a 102 code then the client will know to wait because it is being dealt with.

2xx Success

This type of status code tells us that the client’s request was received, understood, and processed successfully.

200 OK

A response to say that the request succeeded. The information included along with it will be dependent upon which method the request used, for instance:

  • GET an entity that corresponds to the requested resource is sent in the response
  • HEAD the entity-header fields that correspond to the requested resources are sent in the response with no message-body
  • POST an entity that describes or contains the outcome of the action
  • TRACE an entity that contains the request message as received by the end server

201 Created

This means that the request has been completed and a new resource was produced which can be identified using the URI(s) included in the entity that the response relates to, with the most specific URI for the resource given by a Location header field. The response has to include an entity that contains a list of resource characteristics and location(s). A user or user agent can then use this to select the one that’s most appropriate. The entity’s format is defined by whichever media type is presented in the Content-Type header field.
The origin server has to create the resource before it can issue the 201 Created Status Code. If the action can’t be carried out straight away, the server should issue a 202 response (which means Accepted) instead. An ETag response header field can be included in a 201 response to show that the entity tag’s present value for the variant that was requested has just been created.

202 Accepted

The request was accepted for processing, but the processing hasn’t been completed. The request might or might not eventually be acted upon, as it could potentially be disallowed when processing does occur. There is no way to re-send a status code from this kind of unsynchronized operation.

The 202 response is ambivalent on purpose. It’s intended to give a server the chance to look at a request for some other process (maybe a batch-type process that only runs once a day) without any need for the user agent’s server connection to carry on till the procedure has completed. The entity returned with this response has to indicate the current status of the request along with either a link to a status monitor or a rough idea of when the request might be completed.

203 Non-Authoritative Information

The server successfully processed the request, although it’s returning information that might be from a different source. Not found in HTTP/1.0 but found in HTTP/1.1. The returned metainformation in the entity-header isn’t the final set as obtainable from the origin server. Instead, it’s been gleaned from a local or a third-party copy. The set that’s presented CAN be a subset or superset of the original one. For instance, if it includes local annotation information about the resource, this could result in a superset of the metainformation available to the origin server. The use of this response code isn’t a requisite and will only be pertinent when the response would otherwise be 200 (OK).

204 No Content

The request has been completed by the server. It doesn’t need to return an entity-body, but it might want to return updated metainformation though. The response can include new or revised metainformation in the form of entity-headers, and if present these have to be associated with the variant that was requested. When the client is a user agent, it can’t alter its document view from the one that caused the request to be sent.

The main aim of this response is to let input related to actions be entered, without that causing a change to the user agent’s current document view, although any new or updated metainformation has to be applied to the document currently in the user agent’s active view. The 204 response mustn’t contain a message-body, and it’s always ended by an empty line after the header fields.

205 Reset Content

The server has completed the request and the user agent needs to reset the document view that led to it being sent. This response exists so that users can provide input that instigates actions, and then clears the form of that input ready for the next time. The response mustn’t include an entity. This is a little different from a 204 response, where the requester needs to reset the document view themselves.

206 Partial Content

The server has finished processing a partial GET request for the resource. This request needs to have included a Range header field (section 14.35) that specifies the preferred range and was allowed to include an If-Range header field (section 14.27) so the request was made conditional. The following header fields have to be included in the response:

  • Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value has to match the actual number of OCTETs transmitted in the message-body.
  • Date
  • ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
  • Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant

If an If-Range request that employed a strong cache validator was what produced the 206 response then it mustn’t contain any other entity-headers. If it was the result of an If-Range request that employed a weak validator, the response mustn’t include other entity-headers; the idea of this is to prevent inconsistencies between updated headers and cached entity-bodies. In other cases, the response needs to contain all of the entity-headers that would have been returned with a 200 (OK) response to an identical request. A cache mustn’t combine a 206 response with other previously cached content if the ETag or Last-Modified headers don’t match exactly (see 13.5.4). A cache that doesn’t support the Content-Range and Range headers mustn’t cache any 206 (Partial) responses.

207 Multi-Status (WebDAV)

This provides status information for numerous independent operations. (Section 11 contains more information on this).

208 Already Reported (WebDAV)

This code can be used within a DAV: propstat response element to avoid numbering the internal members of several bindings to the same collection again and again. For each binding to a collection that falls within the scope of the request, only one is reported with a 200 status, while subsequent DAV: response elements for all supplementary bindings use the 208 status, and no DAV: response elements for their descendants will be included.

Members in a DAV binding will have been counted in a reply prior to this request and aren’t going to be included again.

226 IM Used

The server has completed a GET request for the resource and responded with a representation of the result of one or more instance-manipulations applied to the present instance. The present instance may not be available except by the combination of this response with other preceding or upcoming responses, as might apply for the specific instance-manipulation(s). If this is the case, the headers of the resulting instance come from a combination of the status-226 response headers and the other instances, as stipulated by the rules in section 13.5.3 of the HTTP/1.1 specification.
The request has to have included an A-IM header field that lists a minimum of one instance-manipulation. The response has to include an Etag header field presenting the entity-tag of the present instance.
A response received with a status code of 226 CAN be placed in a cache and deployed when replying to a subsequent request, contingent on the HTTP expiry mechanism and any Cache-Control headers, and on the requirements contained in section 10.6. A response received with a status code of 226 CAN be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the present instance.

3xx Redirection

This type of status code shows that the user agent needs to take additional action so that the request can be fulfilled. The required action CAN be carried out by the user agent automatically so long as the method used in the second request is either HEAD or GET. A client needs to detect endless redirection loops since loops like this create bidirectional network traffic.

It’s worth noting that in the past, the specification recommended five redirections at most. Anyone developing content needs to consider that some clients might still exist that use this limit.

300 Multiple Choices

Shows a number of choices for the resource that the client can follow, each with its own specific location, and negotiation information driven by the agent (section 12) is provided in order that the user (or user agent) may pick a preferred representation and redirect their request to that location.
Unless it was a HEAD request, the response has to include an entity that offers a list of resource characteristics and locations out of which the user agent or user can select the most suitable one. The entity format is defined by the type of media provided in the header field Content-Type. The most appropriate can be automatically selected, but it depends on their format and the user agent’s capabilities. This specification does not however set any standard for this type of automatic selection. If the server has a preferred choice of representation, it has to include the specific URI for it in the Location field. For automatic redirection, user agents CAN use the Location field value. It’s possible to cache this response where permitted.

301 Moved Permanently

A new permanent URI was given to the requested resource and any future references to it need to use one of the returned URIs. Where possible, clients that can edit links should automatically re-link Request-URI references to one or more of the new references indicated by the server. This response is cacheable except when otherwise indicated.
The new permanent URI has to be given by the Location field in the response. Except when the request method was HEAD, the response entity has to include a short hypertext note that links to the new URI(s).
If a request other than GET or HEAD generates the 301 status code, the user agent mustn’t automatically redirect the request except when the user can confirm it, because otherwise, it could alter the conditions that led to the request being issued.

Note: during automatic redirection of a POST request following the reception of a 301 status code, some existing HTTP/1.0 user agents will change it to a GET request by mistake.

302 Found

For a limited time, the resource requested is residing under a different URI. Because there are times when the redirection might be altered, the client has to continue using the Request-URI for any subsequent requests. This response will only be cached if a Cache-Control or Expires header field indicates that this is necessary. The temporary URI has to be given by the Location field in the response. Except when the request method was HEAD, the response entity needs to contain a short hypertext note with a hyperlink to the new URI(s).
Sometimes the 302 status code might be received following a request that isn’t GET or HEAD, but if this is the case then the user agent mustn’t automatically redirect the request except when it can be confirmed by the user, because doing so might alter the conditions under which the request was issued.

Note that RFC 2068 and RFC 1945 stipulate that the client isn’t allowed to alter the method on the request that was redirected, but the majority of existing user agent implementations treat 302 as if it were a 303 response, executing a GET on the Location field-value without regard for the initial request method. The status codes 307 and 303 were added so that servers wanting to make it as clear as possible exactly which kind of reaction is expected of the client can do so.

303 See Other

The request-response has been stored in a different URI and will need a GET method on that resource to recover it. The main reason for this method is to let the output of a POST-activated script send the user agent to a particular resource. The new URI isn’t a stand-in reference for the resource that was originally requested. The 303 response mustn’t be cached, but the response to the second (redirected) request might be cacheable.
The different URI has to be given by the Location field in the response. Except when the request method was HEAD, the response entity has to contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents don’t understand the 303 status. When such clients need to be operated with, the 302 status code can be used instead, because most user agents react to a 302 response as we describe here for 303.

304 Not Modified

Indicates the resource hasn’t been modified because last requested. If a conditional GET request has been performed by the client and access is permitted but the document has not been modified, then the server has to respond with this status code. The 304 Not Modified response mustn’t contain a message-body and is thus always ended by the first empty line after the header fields. The response has to include the following fields in the header:

  • Date, except when its omission is required by section 14.18.1
  • If a clockless origin server follows these rules, and proxies and clients add their own Date to any response received without one (as previously defined by [ RFC 2068 ], section 14.19), caches will work correctly.
  • ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
  • Expires, Cache-Control, and/or Vary, if the field-value differs from the one sent in any earlier response for the same variant.

If a strong cache validator (see section 13.3.3) was used by the conditional GET, the response must not include other entity-headers. Otherwise (such as when conditional GET used a weak validator), the response mustn’t include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If the 304 response points to an entity that is not currently being cached, then the cache must ignore the response and repeat the request without the condition. If a cache uses a received 304 response to update a cache entry, it will need to update the entry to reflect any new field values given in the answer.

305 Use Proxy

The resource that was requested has to be accessed using the localization field proxy. The field Location provides the proxy URI. It’s anticipated that the recipient will repeat that particular request using the proxy. 305 Reactions only need to be produced by servers of origin. Note: It wasn’t clear from RFC 2068 that 305 was intended to redirect a single request and only be generated by servers of origin. Failure to observe such restrictions has significant consequences for security.

306 (Unused)

The 306 status code isn’t used anymore, and it’s reserved.

307 Temporary Redirect

The requested resource temporarily resides under another URI. Because the redirection may occasionally be altered, the client has to continue to use the Request-URI for future requests. This response is only cachable when indicated by a header field of Cache-Control or Expires. In the response, the temporary URI must be given by the Location field. The response entity has to contain a short hypertext note with a hyperlink to the new URI(s) except when the request method was HEAD because many pre-HTTP/1.1 user agents don’t understand the 307 status. Consequently, the note needs to contain the necessary information for a user to repeat the original request on the new URI. If the status code for 307 is received because of a request other than GET or HEAD, the user agent mustn’t automatically redirect the request except when it can be confirmed by the user, because this might alter the conditions under which the request was issued.

In this case, the request should be repeated with another URI; however, future requests can still use the original URI. In contrast to 302, the request method shouldn’t be altered when reissuing the original request. For instance, a POST request has to be repeated using another POST request.

308 Permanent Redirect (experimental)

This status code says that all subsequent requests should be repeated using another URI. 307 and 308 behave in the same way as 302 and 301 but don’t require an alteration of the HTTP method. So the submission of a form to a permanently redirected resource, for example, can continue as before.

4xx Client Error

The status code type 4xx is intended for instances where the client appears to have made a mistake. The server should include an entity that contains an explanation of the error scenario and whether it’s a temporary or permanent condition, except when responding to a HEAD request. These status codes are applicable to any type of request. User agents have to show any included entity to the user. If the client is sending data, a server implementation using TCP has to ensure that the client acknowledges receipt of the packet(s) that contain(s) the response, before the input connection is closed by the server. If the client continues to send data to the server after closing, the TCP stack of the server will send a reset packet to the client that can erase the unrecognized input buffers of the client before the HTTP application can read and interpret them.

400 Bad Request

Because of bad syntax, the request cannot be fulfilled. The client must not repeat the request without changing it first. A general error would cause an invalid state when the request is fulfilled. Examples of errors include domain validation and missing data.

401 Unauthorized

Like 403 Forbidden, but to be used when it’s perfectly possible to authenticate although this didn’t work or hasn’t been offered yet. The request requires User authentication. The response must include a WWW-Authenticate header field (section 14.47), which has a challenge that applies to the resource being requested. The Customer CAN repeat the request with the relevant Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response tells us that no authorization has been granted for those credentials. If the 401 response includes an identical challenge to the last response, and the user agent has already tried authentication at least once, then the entity given in the response needs to be given to the user, because that entity could include pertinent diagnostic data. HTTP access authentication is covered in “HTTP Authentication: Basic and Digest Access Authentication”.

402 Payment Required

This code has been set aside for use in the future. The initial intention was that this code could be used as part of a form of electronic cash or micropayment program but that outcome hasn’t transpired, so this it isn’t in normal use. Apple’s MobileMe service, though, does produce an example 402 error (“httpStatusCode:402” in the Mac OS X Console log) if the MobileMe account is delinquent.

403 Forbidden

The server has understood the request but is denying it. Unlike a 401 Unauthorized response, authenticating will make no difference and there must be no repeat of the request. If the request method wasn’t HEAD, and the server wishes to say why the request is being denied, the entity’s reason for doing so needs to be outlined. As an alternative, it’s possible to use the status code 404 (Not Found) if the server doesn’t want to that this information to the client.

404 Not Found

Nothing on the server that matches the Request-URI could be found. No indication of whether the condition is permanent or temporary has been given. The status code 410 (Gone) must be used when the server knows that an old tool is indefinitely inaccessible and doesn’t have a forwarding address. This status code is commonly used when the server doesn’t want to reveal exactly why the request was declined, or when there isn’t another answer.

405 Method Not Allowed

For the Resource described by the Request-URI, the method stated in the Request-Line isn’t authorized. The response MUST include an Allow header which contains a list of relevant methods for the resource requested.

406 Not Acceptable

Except when it’s a HEAD request, the response needs to contain an entity with a list of available characteristics of the entity and location(s) from which the user or user agent can select the most suitable one. The format of the entity is dictated by the type of media present in the Content-Type header field. It depends on the user agent’s formatting capabilities as to whether it can automatically select the most appropriate choice. Be aware that the specification doesn’t describe any standards for this kind of automatic selection.
Note: HTTP/1.1 servers may return responses that aren’t acceptable in accordance with the Accept headers sent in the request. Sometimes this can even be the preferred choice to a 406 response being sent. It would be helpful if user agents could pay attention to incoming request headers to check whether they are acceptable or not.

407 Proxy Authentication Required

This code is somewhat like 401 Unauthorized, but it tells us that the client needs to validate itself with the proxy first. The proxy will need to return a Proxy-Authenticate header field (section 14.33) with a challenge that applies to the proxy for the resource requested. The request may be repeated by the client with an appropriate Proxy-Authorization header field (section 14.34). You can find an explanation of HTTP access authentication in “HTTP Authentication: Basic and Digest Access Authentication”.

408 Request Timeout

While it was waiting for the request the server timed out. W3 HTTP specifications state: “The client didn’t produce a request within the time that the server was prepared to wait. The client CAN repeat the request without modifications at any later time.”

409 Conflict

The application couldn’t be performed due to a conflict with the resource’s current state. This code is only permitted in situations where the user is expected to resolve the conflict and to submit the request again. The response body has to include sufficient information to allow the user to identify where the conflict came from. The ideal situation would be for the response entity to offer sufficient information in relation to the problem to allow the user or user agent to resolve it; although that might not be feasible or even necessary. Responding to PUT requests is the most common cause of problems. For instance, when versioning is being used and the thing that’s being PUT includes alterations to a resource that’s in conflict with resources that were created by a prior (third-party) request, the server could use the 409 response to indicate its inability to undertake it. When this happens, the responding entity would probably have a list of the differences between the separate versions in a format that the Content-Type response defines.

410 Gone

The resource that’s been requested can’t be found, there’s no known forwarding address and nor is one likely to be found. If you’re able to edit links, then you should delete any references to this resource. Use a 404 [Not Found] if the server doesn’t know or has no way of finding out if this is a permanent situation. This response can be cashed except when otherwise indicated.
The primary purpose of the 410 response is to help web maintenance. It does this by letting the recipient know that the resource is deliberately unavailable and that the owners of the server want any remote links to it to be taken down. This tends to happen with short-term promotional services and resources and for resources related to people who may have worked with the server but no longer have any involvement. You don’t need to mark every permanently unavailable resource as “gone” or do so indefinitely. That’s entirely up to the server owner.

411 Length Required

The server needs a defined Content-Length before it will accept a request. The client can make the request again so long as it includes a valid Content-Length header field that stipulates in the request message how long the message body is.

412 Precondition Failed

One or more of the request-header fields established a precondition that wasn’t met when the server tested it. This response code can be used by the client to put preconditions on the current resource metainformation (header field data) and by doing so preclude applying the method requested to a resource that isn’t the intended one.

413 Request Entity Too Large

The server is refusing to process a request because the request is larger than the server is willing or able to process. The server CAN close the connection to prevent the client from continuing the request. If the condition is temporary, the server has to include a Retry-After header field to indicate that it is temporary and after what time the client CAN try again.

414 Request-URI Too Long

The URI provided was too long for the server to process. It’s a rare situation that’s only likely to be encountered under certain circumstances, including when the client has converted a POST request to a GET request with excessively long query information, when the client’s become mired in a URI “black hole” of redirection (like when a redirected URI prefix points back to a suffix of itself), or when the server is being attacked by a client that is trying to find a way through the kind of security holes that some servers have using fixed-length buffers that can read and manipulate the Request-URI.

415 Unsupported Media Type

The server won’t process the request since the request entity has been presented in an unsupported format.

416 Requested Range Not Satisfiable

If a request includes a Range request-header field (section 14.35), and none of the range-specifier values in this field are overlapping the current extent of the selected resource, and the request didn’t include an If-Range request-header field, then a server must respond with this status code. (For byte-ranges, this means that the first-byte-pos of all the byte-range-spec values have exceeded the current length of the resource that was selected.) When a byte-range request results in this status code been returned, a Content-Range entity-header field stipulating the present length of the selected resource (see section 14.16) needs to include this in the response. This response mustn’t use the multipart/byte ranges content- type.

417 Expectation Failed

The server can’t meet the requirements of the Expect request-header field, or, if it’s a proxy server it sees a clear indication that the next-hop server couldn’t meet the request.

418 I’m a teapot (RFC 2324)

Actually, an IETF April Fools’ joke that was defined in 1998. The RFC 2324, Hyper Text Coffee Pot Control Protocol wasn’t really intended to be implemented on HTTP servers, but naturally, that hasn’t stopped people from trying. An Nginx HTTP server has used this code to feign goto-like behavior.

420 Enhance Your Calm (Twitter)

The Twitter Search and Trends API returns this when the client is being rate limited. It’s a quote from the movie ‘Demolition Man’ and ‘420’ is probably a nod to the fact that the number’s associated with marijuana. Other services might prefer to use the 429 Too Many Requests response code as an alternative.

422 Unprocessable Entity (WebDAV)

This status code indicates that the server knows what type of content is being requested (which is why a 415(Unsupported Media Type) status code wouldn’t be right), and the request entity syntax is right (which also means a 400 (Bad Request) status code would be equally out of place) but for whatever reason, it still wasn’t able to process the instructions contained in the request. This error condition can sometimes crop up when an XML request body has instructions with the correct syntax, but they contain semantic mistakes.

423 Locked (WebDAV)

The 423 (Locked) status code tells us that the source or destination resource of a method has been locked. This response needs to contain an appropriate precondition or postcondition code, such as ‘lock-token-submitted’ or ‘no-conflicting-lock’.

424 Failed Dependency (WebDAV)

The 424 (Failed Dependency) status code means that the method couldn’t be performed on the resource because the requested action was dependent on another one that failed. For instance, if a command in a PROPPATCH method fails, then, at the very least, the other commands will also fail with 424 (Failed Dependency).

425 Reserved for WebDAV

Slein, J., Whitehead, E.J., et al., “WebDAV Advanced Collections Protocol”, Work in Progress.

426 Upgrade Required

A clear indication of failure is necessary to negotiate reliable, interoperable Upgrade features. The 426 (Upgrade Required) status code lets a server clearly set out the precise protocol extensions a given resource needs to be served with. The client should move to an alternative protocol like TLS/1.0.

428 Precondition Required

The 428 status code shows that the origin server needs the request to be conditional. It’s usually used to avoid the “lost update” problem, which is where a client GETs a resource’s state, adjusts it, and PUTs it back to the server, and while this is happening a third-party has altered the state on the server, which naturally creates a conflict. By insisting that requests should be conditional, the server can ensure that clients are using the right copies. Responses that use this code need to explain how to successfully resubmit it. 428 is an optional status code, which means that clients shouldn’t rely on it to circumvent “lost update” conflicts.

429 Too Many Requests

The 429 status code is saying that the user has sent too many requests during a given period (“rate limiting”).
The response representations need to include details that explain the condition and CAN include a Retry-After header that shows how long to wait before a new request can be made.
When a server is being attacked (or simply being benignly bombarded) with requests from one source, responding to each with a 429 will take up too many valuable resources. Consequently, servers don’t need to use status code 429. When limiting the use of resources, it might be better to something as simple and efficient as dropping connections.

431 Request Header Fields Too Large

This code is saying that the server doesn’t want to process the request because its header fields are too big. The request CAN be submitted again once the size of the request header fields has been reduced.
It can be used when the total set of request header fields are too big, and also when that’s the case with just one header field. In the latter case, the response needs to say which one is too big. Servers don’t necessarily need to use the 431 status code when under attack, as dropping connections is sometimes the more preferable option.

444 No Response (Nginx)

This is an Nginx HTTP server extension that can be useful to deter malware. The server sends no information to the client and shuts down the connection.

449 Retry With (Microsoft)

This is a Microsoft extension that should be retried after performing the most suitable action.

450 Blocked by Windows Parental Controls (Microsoft)

This is a Microsoft extension that appears when Windows Parental Controls have blocked access to a particular webpage.

451 Unavailable For Legal Reasons

As the name suggests, this is used when access to a resource has been denied for legal reasons. Paper ignites at 451°F, which is why this number was chosen. Ray Bradbury’s classic 1953 dystopian novel Fahrenheit 451 explores the society where books are banned and any that are found are destroyed by a dedicated team of “Firemen.”

499 Client Closed Request (Nginx)

An Nginx HTTP server extension. This code appears to log the case when the client closes the connection while the request is being processed by the HTTP server, which means the server can’t send the HTTP header back.

5xx Server Error

When status codes start with “5” this means that the server either knows that it’s made a mistake or it can’t complete the task. Unless it’s responding to a HEAD request, the server has to include an entity that explains what the error situation as, and if it’s permanent or temporary. User agents must show any included entity to the user. These codes will apply to any request method.

500 Internal Server Error

A generic error message that means the server came across a condition that wasn’t expected and it stopped it from performing the request. It’s a generic error message that can cover any situation where the problem is with the server.

501 Not Implemented

The server lacks the functionality needed to perform the request. This response is returned when the server doesn’t understand the requested method or can’t support it for any resource.

502 Bad Gateway

The server was acting as a proxy or a gateway server when it received an invalid response from the upstream server.

503 Service Unavailable

The server can’t deal with the request at the current time because of maintenance or temporary overloading. A Retry-After header can be used to show how long resolving the issue will take. If no Retry-After is given, the client has to act as it would with a 500 response. Be aware that the existence of the 503 status code isn’t meant to suggest that a server has to use it when it’s experiencing overload. It could just refuse the connection.

504 Gateway Timeout

While the server was acting as a gateway or proxy, it didn’t get a timely response from the upstream server that the URI specified (e.g. FTP, HTTP, LDAP) or from a different auxiliary server (e.g. DNS) that it needed to access while it tried to complete the request. Note that some deployed proxies have been known to return 400 or 500 errors when DNS lookups time out.

505 HTTP Version Not Supported

The server either doesn’t support or refuses to support the HTTP protocol version that the request message used. The server indicates that it can’t or won’t fulfil the request using the same major version as the client, as described in section 3.1, except with this error message. The response has to contain an entity that says why that version isn’t supported and what other protocols that server supports.

506 Variant Also Negotiates (Experimental)

A 506 status code means that the server has an internal configuration error: the selected variant resource is set up to take part in transparent content negotiation itself, and so isn’t an appropriate endpoint in the negotiation process.

507 Insufficient Storage (WebDAV)

The 507 (Insufficient Storage) status code tells us that the method couldn’t be conducted on the resource due to the fact that the server can’t store the necessary representation that would allow it to complete the request successfully. This is considered to be a temporary condition. If a user action resulted in the status code that was sent to this request, it shouldn’t be repeated until it’s requested by another user action.

508 Loop Detected (WebDAV)

The 508 (Loop Detected) status code is sent in lieu of code 208, and it’s saying that the server ended an operation because it encountered an infinite loop while it was processing a request. It’s also indicating that the whole operation was a failure.

509 Bandwidth Limit Exceeded (Apache)

Despite the fact that many servers use this status code it isn’t specified in any RFCs.

510 Not Extended

Further extensions to the request are needed so that the server can fulfil it. The policy for accessing the resource wasn’t met in the request. The server should send back all the information necessary so that the client can issue an extended request. It’s beyond the scope of this specification to stipulate how the extensions should pass this information to the client.
If the 510 response contains information that relates to extensions that weren’t present in the original request, the client CAN make the request again if it believes it can fulfill the extension policy by altering the request in accordance with the information given in the 510 response. Alternatively, the client CAN offer any entity mentioned in the 510 response to the user, since that entity may have pertinent diagnostic information to contribute.

511 Network Authentication Required

511 indicates that the client needs to authenticate in order to gain network access.
The response representation has to contain a link to a resource that lets the user send credentials (as it would with an HTML form, for example).
Be aware that the 511 response mustn’t offer a login interface itself or a challenge because (somewhat confusingly) browsers would show the login interface as being associated with the URL that was initially requested. Origin servers should not produce the 511 status. It’s meant to be used by intercepting interposed proxies in order to control network access.
511 status code responses mustn’t be cached.

The client needs to be authenticated in order to receive network access. This code is intended to alleviate difficulties attributable to “captive portals” to software (especially non-browser agents) when that software is expecting a response from the server that a request was made to, not the network infrastructure in between. It isn’t intended to discourage the deployment of captive portals, just to minimize the damage they can cause.

A network operator who wishes to specify some authentication, acceptance of terms or some other user interaction before allowing access to the user will typically do so by identifying clients who haven’t done so (“unknown clients”) via their MAC addresses.

Subsequently, unknown clients will have all traffic blocked unless it’s on TCP port 80, which is routed to an HTTP server (the “login server”) and is specifically there for “logging in” unknown clients, and naturally, traffic to the login server itself.

A response that carries the 511 status code well typically be sent from the origin server shown in the request’s URL, presenting a multitude of security issues. Examples include when an attacking intermediary inserts cookies into the namespace of the original domain, observes cookies or HTTP authentication credentials sent from the user agent.
These risks aren’t confined to the 511 status code though. A captive portal that doesn’t use this status code throws up the same kinds of difficulties.
Also, be aware that captive portals employing this status code on an SSL or TLS connection (commonly, port 443) will produce a certificate error on the client.

598 Network read timeout error

Not specified in any RFCs, but some HTTP proxies use it to indicate a network read timeout behind the proxy to a client that’s in front of the proxy.

599 Network connect timeout error

Not specified in any RFCs, but some HTTP proxies use it to indicate a network connect timeout behind the proxy to a client that’s in front of the proxy.

Getting the Best WordPress Hosting Performance Today

WordPress Hosting Performance Today

Fast, performant, and close to home? It sounds like a line from an ad. But it’s not. It’s about what a hosting provider should offer a WordPress business. So let’s dive into the behind-the-stage attributes that will give you ultimate WordPress Hosting Performance.   

To have great WordPress performance, you should look for the following magic features: CDNs and your server location. A data center that’s geographically-close to its users guarantees low latency. While CDN ensures excellent response times to users worldwide. Let’s call them the salt and pepper of the WordPress hosting performance dish. Read on to discover the rest of the equally important ingredients.

The WordPress Community on WordPress Performance

We asked the WordPress Community for a top tip to boost WordPress Performance. Here’s what we got. 

Must-Have Hosting Performance Features

WordPress needs hosting. Which WordPress performance attributes would make the latter one the best match?

Optimizing Speed and Performance - Ruby on Rails vs PHP

Server-level Caching and CDNs

Server level caching is a great way to provide a significant performance boost to most websites with a lot of static content (images, CSS, HTML). While CDNs also perform caching, it’s good to have a server-level caching by default.

Speaking of Content Delivery Networks, the providers who offer a CDN with the selected WordPress plan score higher in the attractiveness top. Even upper on this list are the providers who offer a CDN that’s integrated into a control panel.

HTTP/2 and DNS

Also, the hosting provider or CDN one must enable the HTTP/2, the latest major revision of the HTTP Protocol. Moreover, to make a good impression and provide the best possible performance for the users, Gzip compressing should be part of the offering.

A performant hosting experience includes offering a fully-featured DNS service. The providers which offer restricted DNS or domain features (like adding a parked domain, add-on domain or subdomain) don’t make the best impression.

First Byte 300ms or Less

Can it make it in under 300 milliseconds? Then, it’s a keeper. For the end-users, it means their browser will receive the first byte of response within this time-frame. Apparently, 300 milliseconds or less is the golden number – according to numerous e-commerce studies.

Detailed WordPress Performance Benchmarks

stats - NGINX vs Apache - Plesk

“We want it all and we want it now”. These are the expectations we hear from customers browsing online platforms. This is why speed and performance play a major role in the success of any online business. Website performance is about retaining users, improving conversions, making customers happy – and ultimately, growing your business.

Studies say you have just 27 seconds to make a first good impression. When you have an e-commerce website, you have even fewer seconds at your disposal. Neil Patel, digital marketing guru, states that 40% of people abandon a website that takes more than 3 seconds to load. Moreover, Google penalizes slow and poorly performing websites from an SEO perspective and downgrades search engine rankings.

Therefore, other than the managed WordPress hosting plans, how a provider handles various levels of traffic in real-time is also very important.

What Makes the Difference?

  • Concurrency is the number of multiple simultaneous users that are connected to your application, requesting content as quickly as possible. But not all at once.
  • Meanwhile, Requests Per Second (RPS) represents the number of requests the web server can respond to within 1 second. Sites with higher RPS will be able to handle more traffic.
  • As for the latency, it represents the response time observed for 95% of the requests sent during a time frame.

Why Geography Impacts Performance

location - CDN - globe

How do you feel about long-distance connections? They may work, but with some struggle. This also applies to your WordPress hosting, so that you can get the bets WordPress Hosting Performance.

Your website may not perform at its best if the location of the data center that hosts it is not close to your audience. Picking a data center in the same city as your audience will provide much lower latency.

An ideal scenario would be to have two data center locations in the same region to deliver at full speed dynamic content. In particular, PHP generated content dynamically, which can’t be cached easily. And even all your users are in the same area as your data center, you don’t want to lose points for high latency.

This is why using a CDN comes handy. As a Content Delivery network helps you to deliver excellent response times to users worldwide.

Top WordPress Hosting Performers and Why

So, now you know what to look for in a WordPress hosting provider. But do such ideal hosting providers exist? Well, yes. According to Cloud Spectator Report, the best ones, in terms of performance features, are:

  • FlyWheel
  • Kinsta
  • Pantheon

All three of them are A-class hosting performers because they have in place: server-level caching, HTTP/2, gzip compression, premium DNS, First Byte at or under 300ms in at least 1 location, CDN available and CDN management.

WordPress Hosting Performance Features

FlyWheel and Kinsta are top performers also in regards to Global Reach. Pantheon got maximum points for Backup and Restore features, too. For Staging & Cloning, both Pantheon and Kinsta got gold medals. Kinsta received a two more on WordPress Support, respectively Onboarding chapter.

Nevertheless, on Developer Friendly, General Support, respectively Security Features aspects, other providers got into the spotlight. However, none of the 17 providers included in the international benchmark study achieved top scores across all nine listed categories.

Important takeaway: as a WordPress owner you need to determine which feature sets are vital for your needs before selecting a WordPress Hosting provider.

How Plesk Impacts Your WordPress Performance

Speed Up WordPress Website

Lots of points to consider when choosing the best-performing WordPress hosting provider for you, right? Fortunately, there is another way to get the same perks, but without any headache. While using Plesk Hosting Platform for your virtual or dedicated server, you can also use the WordPress Toolkit extension on top of it.

Instant benefits? Everything becomes simpler regarding configuration, routine management or overall performance of all your WordPress projects. Remember that Google likes performant websites and ranks them higher in the search results.

Discover more ways to turbocharge your WordPress Performance here.

To keep it short and simple: a fast and well-optimized WordPress website will do the work. And happy visitors can become satisfied customers later on.

Moving from HTTP to HTTPS 3: Troubleshooting and DIY solutions

Moving from HTTP to HTTPS 3: Troubleshooting and DIY solutions - Plesk

One thing is quite clear- HTTPS is here for good. When SSL certificates give you HTTPS status, you’re saving user data from hackers, making the internet a safer place. You’re also increasing online transactions on e-commerce sites. That’s why most serious website owners have already migrated from HTTP to HTTPS – or are attempting it.

However, even with a host of benefits for a Google-friendly HTTPS site, there are certain technical issues associated with its integration or maintenance that may puzzle even technical users. Let’s now talk about such issues and the best possible ways to resolve them.

Optimizing Speed and Performance

This article presented some tricky errors along with their easy, DIY solutions. Let us know in the comments if we’ve managed to keep the instructions clear and simple and if you performed all the steps accurately.

Optimizing Speed and Performance - Ruby on Rails vs PHP

It’s not uncommon to experience site performance/speed issues after upgrading to HTTPS. SSL-enabled sites go through a series of additional verification processes when a visitor enters. One of the key processes is the handshake that requires a significant amount of CPU power. Here are a few actionable tips that can minimize the operation series and resolve this issue.

  1. Save time by sending multiple requests through a single connection. For that purpose, you need to enable Keep-Alive connections.
  2. Shave time by reusing the SSL session parameters. It will eliminate the SSL handshakes requirements for subsequent or parallel connections.
  3. SSL session cache stores multiple sessions. This cache is shared between all the workers. Use ssl_session_cache directive to enable it.
  4. There are 4000 sessions per megabyte of cache and its default timeout is 5 minutes However, you can increase this time for the better results by using the directive ssl_session_timeout.
  5. To further enhance your website speed by 50-300%, you may also consider the downloadable Speed Kit extension on Plesk.

Issues regarding SSL certificates

Issues regarding SSL certificates - Plesk

SSL Certificate Chains

Another tricky situation is when browsers refuse to accept a certificate, even from a reputed authorized CA. The most popular browsers generally have an inbuilt certificate base containing variously authorized and reputed CAs. However, the reputed CAs use intermediate certificates to sign the server certificate.

The series of chained certificates are provided by the CAs that ultimately link to the root certificate. These intermediate certificates aren’t in the browsers’ inbuilt certificate store and it causes the error. Here are the actionable tips you can follow.

  1. Ideally, the chained certificates should follow the server certificates in order to enable the operations/process.
  2. If you’re non-technical, it’s good to get help from a professional or CA.
  3. Open certificate details and :certification path will reveal the problem areas.
  4. Communicate with your CA if you find difficulty installing an intermediate certificate.

Invalid SSL Certificate

If you try installing the certificate with incorrect details, you’ll get this error. Here’s what to do.

  1. Let’s Encrypt users can use the renewal command to renew an SSL certificate.
  2. If you purchased from another CA, ask them for an SSL certificate renewal.
  3. Make sure the CA is reputable and recognized by popular browsers.

Outdated SSL certificate

As the name suggests you need to renew your SSL certificate because it is now past its due date or has some validity issues. If your browser doesn’t support SNI, then updating its version can resolve the issue. You may also try revisiting the same page.

The Mixed Content Issue

When you use an HTTPS domain as a path to send HTTP elements, it causes the mixed content error. Basically, you’re trying to mix the different elements (HTTP and HTTPS) on the same platform. Here’s how to solve it.

  1. Just visit the console tab in chrome dev tools where you can find a series of elements. If the elements are hard-coded, you need to modify the URL manually. For external resources just replace the HTTP versions with HTTPS. If the external resources haven’t yet transferred to HTTPS, you can send them a request. Alternatively, you can also look for the HTTPS substitutes to the external resources, like images.
  2. Review the certificate information of the custom SSL certificate that you’re adding to CDN/Origin server and make sure all the information is correct and current. Things to check: intermediate certificates (check entire range  separately ), Private key, empty lines (delete if you encounter any).
  3. Use some reputable tool that can help generate an intermediate certificate.

Outdated Browser, Cache and Cookies

Older browsers may be unable to recognize the SSL-enabled sites because they don’t support these technologies. If browsers cache has saved the older SSL information about your site’s recently-updated certificate, then this message appears due to an info mismatch.

This error may still occur after you solve the problem. resolving the problem if that problem. The simple remedy is to clear your cache so your browser can again retrieve and read the updated certificate details.

Apache Issues

Apache Issues - Plesk

For Apache issues, you need to use codes. Digicert, leading SSL authority, provides a complete guide on how to resolve such issues. Along with solution codes that you might just need to copy/paste. With Digicert, you can also diagnose your SSL issues here, provide your site name and check for the reports.

Further DIY Solutions to HTTPS Issues in Plesk

If you love DIY exercises, then here are different ways to buy, manage or renew your SSL certificate in Plesk. All you have to do is to click the links below and follow the easy instructions.

  1. Change the default certificate
  2. Renew the default certificate
  3. Purchase SSL Certificate from Plesk
  4. Enable redirection from HTTP to HTTPS in Plesk
  5. Download SSL certificate in Plesk

This article presented some tricky errors along with their easy, DIY solutions. Let us know in the comments if we’ve managed to keep the instructions clear and simple and if you performed all the steps accurately.

arrow icon - Plesk

Moving from HTTP to HTTPS 2: SSL Certificates and their suitability

SSL Certificates

SSL certificates help secure data in transit against attacks. Regardless of their types or issuing agency, all SSL certificates encrypt submitted data – decrypting it only upon reaching its recipient. While this basic functionality remains the same for all types of SSL certificates, there are some key differences in suitability and limitations. Let us explore these differences in detail as you continue your move from HTTP to HTTPS.

DV (Domain-validated) Certificate

DV (Domain-validated) Certificate - Plesk

DV or domain validate certificate is the most basic level of certification. It simply helps you demonstrate that you’re the submitted domain owner, while requesting the SSL certificate.

A DV certificate is ideal for internal communications, to maintain test domains and servers, and internal sites. Rarely, it may also be suitable for small businesses with a brochure website.

DV Certificate Limitations

  1. DV doesn’t mention the company name that owns and operates the domain. Hence, it doesn’t verify the domain is owned by a trusted, official, legal entity. This can discourage shoppers or potential partners from sharing their personal info while performing online transactions on your site.
  2. Sharing data over a secured network with an unidentified/unverified recipient isn’t wise. A hacker can purchase a fraudulent similar sounding domain name and its SSL certificate (like or This just to trick visitors into sharing sensitive data which they will later misuse.

OV Certificate

OV Certificate - Plesk

You get an OV certificate after a detailed verification process. Because it displays more comprehensive domain information, thus verifying that the legal corporate entity that owns it is authentic.

An OV Certificate is suitable if you’re running a commercial website or blog that requires clients to login using an ID/password. Or for educational institutes that require students/teachers to login and check reports/attendance and other non-interactive activities. An OV may also suit local community websites and small business websites that don’t involve sales or sharing of payment details.

OV Certificate Limitations

  1. Real human interaction like the telephonic call is generally involved at multiple levels that enhance the trust level.
  2. Trusted real-world sources are checked to cross-verify the corporate nature of the business requesting it. In most of the cases, it also involves the submission of business documents.

EV (Extended Validation) Certificate

EV (Extended Validation) Certificate - Plesk

EV certificates almost eliminates any phishing possibilities because of its strict configuration, reinforcing failsafe security at multiple levels. However, an EV requires the most stringent verification process. Your organization can have one issued only after it can successfully pass all verification steps. Namely, physical existence, current legal/operational status, exclusive domain ownership and controlling rights of the commercial entity.

EV Certificate Suitability

  1. The EV certificate is perfect for online stores that need customer personal and payment information. Including contact address and phone number.
  2. EV is also suitable for Healthcare websites that establish communication between doctor and patients. Also, government, educational and other interactive websites that conduct online tests, assessments and such.
  3. If you’re working on mission-critical projects via your website, then an EV SSL certificate is the best option for you.
  4. The EV certificate is also the best choice for online wealth building and management sites and Blockchain websites. Those enabling online payments and are looking to build a long lasting digital empire.

Single Domain SSL certificate

The single domain covers only one main domain to which it belongs, without supporting any of its subdomains. So if you buy a single domain certificate for, it will only provide SSL security (and HTTPS status) to The Single Domain SSL certificate is ideal for small businesses and start-ups that just want to secure one domain. Like the homepage.

Wildcard SSL Certificate

Wildcard SSL Certificate - Plesk

Along with securing the main domain, the wildcard certificate also secures all related subdomains. In short, the Wildcard perfectly fills the gaps left by the single domain certificate. For instance, if you purchased a Wildcard SSL Certificate for, then it will automatically secure,, and

A Wildcard SSL certificate is best for business websites, institutional sites and other websites with multiple web pages of high importance. Such as government organizations, eCommerce sites, online new media, and social community websites.

Multiple Domain Names Certificate

The Multiple Domain names SSL certificate is fully capable of securing multiple domain names that belong to you. The Multiple Domain Names Certificate is suitable if you’re running a group of companies with different URLs or you’re considering starting up multiple blogs or sites in the future.

HTTP to HTTPS: Get the best benefits from your SSL Certificate

You need to know about various options and their suitability for you to make the best SSL choice. Especially with the move from HTTP to HTTPS. This article should help you evaluate this in the context of your business and its objectives. If you’d like to know more about the suitability of different certificates, read our SSL Certificate guide here or the more detailed SSL info from Digicert.

Moving from HTTP to HTTPS 1: Avoiding the SEO Pitfalls

Moving from HTTP to HTTPS 1 - Plesk

If you’ve recently moved your site from HTTP to HTTPS, or are planning to soon, then be sure not to make a costly SEO mistake. While moving your site, you’ll make several changes that may harm your SEO, if not made correctly. But fortunately, you’ve landed on this guide to help you out with a few straightforward steps.

HTTP to HTTPS: Use Appropriate Redirects

If you’ve recently moved your site from HTTP to HTTPS, or are planning to soon, then be sure not to make a costly SEO mistake. While moving your site, you’ll make several changes that may harm your SEO, if not made correctly. But fortunately, you’ve landed on this guide to help you out with a few straightforward steps. Use Appropriate Redirects

When you use a 302 page redirect, Google starts indexing the new HTTPS version, but does not stop indexing the older HTTP version. Because Google considers the two HTTP and HTTPS versions different properties.

This separate indexing prevents the SEO juice and other qualities of your old URL to be passed onto your new HTTPS version. Thus, making all your previous SEO efforts on the old HTTP version redundant, and you may need to start again from scratch. However, when you redirect to 301, Google indexes the 301 targeted URL and discontinues crawling the older version. Resulting in more than 90% of SEO juice transfers to the new HTTPS version.

Avoid chained redirects

Google cannot crawl more than five chained redirects. So, it’s wise to include all your existing redirects to the initial HTTP to HTTPS redirect. Thus, making things easier for Google can certainly help your SEO. WordPress sites can use redirection to manage redirects or this redirect checker to trace redirectchain.

Don’t redirect to a single irrelevant destination

Redirecting different old URLs to a single irrelevant location creates unnecessary confusion and negatively affects the user experience. However, if you consolidated contents from multiple old URLs to a single page, then it’s fine to redirect them there.

Enhance Crawling Efficiency

Enhance Crawling Efficiency - Plesk

Different post-move processes for SEO/search engine updates would need to recrawl your site. If your site is complex and large, it can affect crawling efficiency and delay the process. Here are a few tips to increase efficiency and reduce time:

  1. Admin Pages, backend folders and other irrelevant pages waste significant time for search engine bots. So, prevent them crawling through these sections by editing the robots.txt file.
  2. Bots don’t interpret graphics. So, images should come with proper image alt-tags to make them bot-friendly.
  3. Interlink old content at the relevant portions of the new content. It will help with deep crawling and add to its value.
  4. Consider one of various free or paid tools available that enhance crawl efficiency, thus speeding up the process altogether.

Check crawling behaviour and response codes

Keep a close eye on the crawling behaviour of Google bot on both versions, from HTTP to HTTPS. Along with checking the crawled URLS, you also need to look at the response codes the Google bot receives via analytics. To facilitate this information, you’ll need to upload server log files.


Robots.txt - Plesk

Robots.txt is a vital source of your technical search engine profile. So after the move you need to check Robots.txt once or twice and make the necessary changes.

  1. Carefully check HTTPS robots.txt to ensure its content matches the previous listed for that HTTP version and that it doesn’t disallow all.
  2. The HTTPS pages should not have any Meta ‘no index’ attributes and the HTTP robot.txt file shouldn’t disallow all. It should either redirect or deliver 404 as applicable.
  3. Blocking HTTP URLs in robots.txt prevents the search engines from seeing the HTTPS URLs redirects. Thus, various vital signals like Pagerank etc. will not be transferred.

Update HTTP resources immediately

Most possibly you could be using some external resources on your website like images and social communications. Make sure you update all such resources in the page source code so that they point to the HTTPS versions. In case a resource doesn’t have a HTTPS version, it may be better to look for substitutes from a secured source.

Also note that the presence of HTTP elements on the site can attract a ‘No Secure’ warning. Thus, defeating the very objective of buying an SSL certificate.

Change your Metadata and structure markup to align with your new HTTPS status and help you maximize ranking benefits. Namely canonical and pagination attribute, hreflang and rel alternate media, and structured mark-up (example: breadcrumbs and videos).

Then, communicate the HTTP to HTTPS changes to Google by verifying the HTTPS property in Google Search Console. Make a property set that is the combination of HTTP and HTTPS properties to facilitate monitoring. Then set ideal configuration for handling parameter for HTTPS version in the search console itself.

Hosting panel resources for non-technical users

There are some really good, reputable hosting panels offering easy documentation and step-by-step guidance. Plesk is among one of the top choices for non-technical users because of its neat interface and multi-OS support. If you’re using Plesk, you’ll first need to install SSL certificates for your domain. Also make sure that you have enabled SSL/TLS support in your domain Hostings Settings.

Linux OS and Plesk users

If you use Linux OS then access your .htaccess file in Plesk and paste the following link:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,QSA]

Click OK and you’re done.

Web.config file for Plesk and Windows users

Access you web.config file under file manager and paste the following code just before  </system.webServer>:

<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
<action type="Redirect" redirectType="Permanent" url="https://{HTTP_HOST}/{R:1}" />

HTTP to HTTPS is a wise move if you can dodge the negative SEO impacts that may result. Hopefully this article has accomplished that for you. For more info, here’s the detailed guide on different SEO-friendly HTTPS redirection methods in Plesk.