Note that in case the user agent is a search engine spider or a software application, there is not a user
involved in the process, as shown in Figure 4-3. Search engines follow the same basic process to update
SERPs when they encounter a redirect.
Redirections can be chained, that is, one redirect can point to a page that, in turn, redirects again. However,
multiple redirects should be avoided to the extent that it is possible. A maximum of five redirections was
stipulated by an older version of RFC 2616, but that limit was later lifted. Regardless, it is wise to avoid
chained redirects because they can slow down site spidering — spiders may only
the result of
the redirection for spidering instead of immediately fetching it.
We recommend chaining no more than three redirects.
The HTTP standard actually contains many redirection status codes. They are listed in Table 4-1.
In practice only the 301 and 302 status codes are used for redirection. Furthermore, because browsers are
known to struggle with certain of the other status codes, it is probably wise to avoid them, even if they
seem more relevant or specific. It can only be assumed that search engines may also struggle with them,
or at least that it is not entirely understood how they should be interpreted.
URL A replies with a
status code indicating
a redirect to URL B
Web server at URL A
URL B replies with a
status code of 200 and
some HTML content
Web server at URL B
User requests URL A
User is displayed
the content received
from URL B
Web client requests URL A
Web client requests URL B,
updating the address bar to
display URL B
Web client reads the
content received from
Chapter 4: Content Relocation and HTTP Status Codes
c04.qxd:c04 10:40 80