A website’s structure can be altered by deleting pages or moving to another domain. Using redirects appropriately is essential to prevent losing search engine rankings and for search engines to understand the modifications you have made.
The status code for redirects begins with the number three (i.e., 3XX). Fewer than a dozen of the 100 available status codes are used to communicate specific information.
301: Permanently Moved
If you see this well-known redirect, it means the resource has moved, and you should start using the new URL in your future requests. Search engines can transfer a 301 redirect’s ranking to a new page.
If you decide to employ a 301 redirect, you need to be careful. If you later decide to remove the 301 redirects, your previous URL may no longer rank. This is why.
Changing the redirects won’t help you regain the former page’s ranking position. The most important thing to remember is that a 301 redirect cannot be undone.
To avoid any misunderstandings, we’ll call it a “client” instead of a “browser” because browsers and search engine bots are capable of browsing URLs.
307: Short-Term Redirection
This signifies the resource has been temporarily relocated, and subsequent requests should be made using the original resource’s URL, as defined in HTTP 1.1.
Customers should be sent to a new website, but search engines shouldn’t change their SERP links to go to it.
PageRank is not sent from the original resource to the new one in a 307 redirect, unlike 301 redirects.
302: No such file or directory was found.
HTTP 1.1 looked for the resource at a different URL; HTTP 1.0 looked for it at a different URL because it was temporarily moved. 302 vs 307
302 and 307
redirects are almost always handled the same. However, a 302 status code does not always imply that the client must follow a redirect, and it is not deemed an error if it chooses to remain in the current location.
Even though most modern clients are likely to follow the new URL, some older clients may mistakenly stick with the old one.
307 ensures that the request method will not be altered instead of 302. For example, the GET request must continue to GET, and the POST request must continue to POST.
A 302 status code can cause unexpected behaviour in old or unstable clients.
Temporary redirects can be done with 302 or 307, although I prefer 307 because it’s shorter.
You should employ 301 (permanent redirect) and 307 (temporary redirect) status codes, depending on the type of modification you’re making to your website, for normal redirect duties. There is no difference in the syntax of redirects in either scenario.
If you’re using Apache or Nginx, you can use the. Access or example.conf files in your server configuration, or use WordPress plugins to handle redirects.
Redirect rules are written the same way in all cases. The only place where they diverge is in the configuration files’ commands. When using Apache, a redirect looks like this:
Symlinks can be found here for more information.)
It will look like this on Nginx servers.
Using the command to tell the server’s redirect status code is different from using the command to take action. Take, for example:
A “301” redirect instead of a “permanent.”
“RedirectMatch” vs “rewrite” as the command to take action.
Redirecting to a new folder has the same syntax no matter where you put it.
As a precaution, ensure your Apache server has mod rewrite, and mod alias modules enabled.
Here are some samples of Apache. htaccess files because that is the most common server type. These two lines should be in the. htaccess file above the redirect rules and below them.
The accompanying table on RegExp basics can help you comprehend the examples below.
Make a single URL redirection.
Delete or rename a page’s URL, and a redirect will be used to point to the new URL. This is an example of how URLs can be altered. In this case, the redirect rule would be as follows.
Aside from the fact that Apache mod-rewrite is used in the first technique, mod alias is used second. There are two ways to go about it.
When using regular expressions, the URL must begin with the “/old-page/” prefix, while (/?|/.*)$ indicates that everything after the prefix must be forwarded to the corresponding URL.
It is possible to use (.*) instead of /old-page(.*), however, this has the disadvantage of rerouting /old-page-other/ as well, which is not what we want.
A new page will be created for the following URLs:
A new URL will be created for any URL variation. In this case, the redirection would look like this: To avoid the problem of 404 errors when UTM query strings, such as /old-page?UTM source=facebook.com are included in the URL; regular expressions are needed.
No matter how old the page is, it will return an error code 404.
Everything Else But
All of our former subcategories, like /category/old subcategory-1/, will be combined into the final subcategory; thus, we’ll need to consolidate all of these URLs into one. It’s time to bring in the “all but” rule.
On the third line, except for /category/final-subcategory/, we want to redirect everything under /category/. You can see “!-f” on the second line, which implies disregarding all files, including images and CSS.
The problem is that if we have some assets like “/category/image.jpg,” they will likewise be diverted to “/final-subcategory/” and cause a broken image.
Changes to the directory
If you’ve recently restructured your categories and want to migrate everything from the old directory to the new one, you can use the following rule.
With $1 in the target, I’m instructing the server to keep track of anything in the URL after /old-directory/subdirectory/ and pass it along to the destination (i.e., “/subdirectory/”). As a result, /new-directory/subdirectory/ will be the new destination.
One example had no trailing slash, while the other had a slash at its end.
Using (/?|.*)$ RegExp at the end would combine them into one rule, but this would cause issues and add a “//” slash to the end of URLs with no trailing slash that had query strings (e.g., “/old-directory?UTM source=facebook” would be redirected to “/new-directory/?utm source=facebook”)…
The URL has a misspelt word.
Let’s imagine you want to get rid of all 100 URLs on your website that contain the word “Chicago.”
Redirecting to http://yourwebsite.com/example-chicago-event/, for instance, might look like this:
Redirect will be as follows if the example URL is in the form http:// yourwebiste.com /example /chicago/event/.
If you don’t have it, search engines will regard URLs with “www” and “non-www” versions as separate pages with the same information, putting your website at risk of duplicate content issues.
Because of this, it is imperative that you only use one version of the website at a time.
If you want to use the “www” version of your website, follow these instructions:
This is a “non-www” version:
URLs with a slash at the end or without one are also treated differently as part of canonicalization.
This will ensure that the URL /example page is redirected to /example page. If you decide to remove the slash rather than add it, you’ll still need the following rule:
Redirect from HTTP to HTTPS
Many websites now redirect to HTTPS due to Google’s recent campaign to urge webmasters to utilize SSL.
For every website, the following rewrite rule can be applied.
You can use this to aggregate redirects for both www and non-www URLs into a single HTTPS redirect rule.
A 301 redirect from an old URL to a new one
If you’re rebranding your company and need to switch to a new domain, this is a common redirect to use. Redirecting old-domain.com is done by using this rule.
A “www” URL and a “non-www” URL are used in this example because a page may contain incoming links to both URLs for historical reasons.
The majority of WordPress sites don’t require the use of a.htaccess file to redirect traffic; instead, they can rely on a plugin.
While utilising plugins to manage redirects, there are a few things to keep in mind, such as reading their documentation to learn how to handle RegEx correctly.
Redirection, a free plugin with a plethora of configuration options for customizing redirect rules, comes highly recommended from the ones already available.
Redirect Unacceptable Behavior
1.First, redirecting all 404 Broken URLs to the Home Page is the best option.
It’s easy to fall into this trap if you don’t go through all of your 404 error pages and assign them to the correct landing page.
They’re still 404s, according to Google.
If you have a lot of 404 pages, you may want to try designing stunning 404 pages that encourage visitors to continue browsing or to search for something else entirely.
According to Google, it is strongly suggested that redirected page should be identical to the original page’s content. The ranking of that page may be impacted due to a soft 404 if such a redirect is used.
2. Incorrect redirects to mobile-specific pages
Make sure to lead customers to the appropriate page of the mobile version of your desktop, and mobile websites have different URLs (e.g., “yoursite.com” for desktop and “m.yoursite.com” for mobile).
M.yoursite.com/sport/” is the correct URL.
It should be “m.yoursite.com” instead of “yoursite.com/sport/.”
Additionally, if a page returns a 404 on a desktop, it should do it on a mobile device.
The desktop version of a page can be used instead of forwarding to a mobile version if one is not available.
3.Using Meta Refresh
Meta refresh tag can be used to redirect, as seen in the following example: meta http-equiv=”refresh” content=”0;url=http://yoursite.com/new-page/” />
The user will be redirected to /new-page/ immediately if you include this tag in the old page. Google does not restrict the use of this redirect, but they advise against it.
4.Too Many Redirects
As a result of an incorrect regular expression, this message is displayed.
When you have a redirect chain, this usually occurs.
Suppose you’ve been redirecting pages 1 and 2 for quite some time now. You may have forgotten that page1 is redirected and decided to reroute page2 to page1.
In the end, you will have something like this:
An infinite loop will ensue, resulting in the error seen above.
Once a permanent redirect has been set up, it cannot be changed back (the word “permanent” meaning “hard”).
That’s because Google will update the URL in the SERPs to utilize the new one whenever it detects a redirect.
Migrating a large website with thousands of pages from one domain to another, or even from HTTP to HTTPS to HTTP, requires first performing a 302 temporary redirect and then checking Google Analytics data to ensure that no unexpected outcomes (such as a syntax error that results in massive amounts of 404 pages) have occurred. Then, the 301 permanent redirects can be performed.
Three hundred one permanent redirects should not be chained together if you are changing the redirect URL and want to avoid redirecting visitors to the wrong URL.