From this page on the blog of Matt Cutts, he says that rel=canonical should be a secondary choice if you can't use a 301 redirect. Is there any performance issue with using a 301 redirect instead of a rel=canonical?
In my experience, the performance difference is negligible. There are more steps involved in the implementation of 301 redirects, so rel=canonical might perform slightly better. The extra steps are typically executed very quickly and should not add any noticeable delay or strain on server resources.
rel=canonical
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server builds a page that includes the canonical tag and sends it to the user
301 Redirect
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server issues a 301 redirect to the canonical URL.
User's browser automatically makes a second request for /canonical.html
Server discovers that this request is for a canonical URL.
Server builds a page and sends it to the user.
Related
I have an ASP.NET website. A user can access the URL /partners/{partner-id} in my app. When that url is invoked, I do two things:
1) I want to log the partner ID and user that requested it and
2) Redirect the url to the partner's website.
My question is, which HTTP Status Code should I use? I was using 301. However, that introduced a problem where my logging code was getting skipped. I suspect its because a 301 represents a permanent redirect. However, I basically want to remain the middle man so that I properly log the details.
What HTTP status code should I use?
Thanks!
Taking a look here:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
you should use the 302 status code. Two useful points about the 302 redirect:
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests
This says by inferring that the redirect may be temporary, clients should always check the initial URI instead of going to the redirect URI as a default behavior, meaning they will pass through your logging system each time rather than going directly to the redirected URI on subsequent requests. The 302 response also states:
This response is only cacheable if indicated by a Cache-Control or
Expires header field.
By default, the 301 redirect is cacheable unless you explicitly specify, but the 302 is not cacheable unless explicitly specified.
However, it's probably a good idea to explicitly add in 'do not cache' headers to the redirect to let the client know that it should not be cached just in case you have a client that doesn't follow the default spec behavior. There are a number of other answers in stackoverflow regarding this, here's a decent one:
How to control web page caching, across all browsers?
I am new to ASP.Net 4.0, and have seen a new feature called Response.RedirectPermanent(). I have checked a few articles, but I'm unable to understand clearly the actual meaning and difference of Response.RedirectPermanent() over Response.Redirect().
According to Gunnar Peipman,
Response.Redirect() returns 302 to browser meaning that asked resource is temporarily moved to other location. Permanent redirect means that browser gets 301 as response from server. In this case browser doesn’t ask the same resource from old URL anymore – it uses URL given by Location header.
Why do I need to check the server response such as 301, 302? And how does it get permanently redirected the page to the server?
301 response (RedirectPermanent) is very useful for SEO purposes. For example, you had a site implemented in ASP.NET WebForms and redesigned using ASP.NET MVC. You'd like to inform search engines that page /Catalog/ProductName.aspx becomes /products/product-name. Then you set 301 redirect from /Catalog/ProductName.aspx to /products/product-name and links in search engines' indices will be replaced. 302 (Redirect) is mostly for internal purposes. For example, the redirect after login (if returnUrl was set in URL).
My company is embarking on a large website redirection at the moment and I decided it would give us the perfect opportunity to make the URL's more user and google friendly.
To give you a brief outline of the situation, I am the SEO guy and I am dealing with an external developer in order to redirect the website without hurting the current rankings in Google. I don't have much experience regarding sharepoint hence why I would really appreciate any assistance in understanding and knowing if there is a work around to my situation.
The website is using IIS7.5, they recently installed the URL Rewrite Module in order to create more user friendly URL's. My question is, by creating a more user friendly URL, does this cause an additional redirect?
For example: if a user types in www.domain.com this permanently (301) redirects to www.domain.com/pages/home.aspx.The developer told me that in order to rewrite the URL to display something more friendly (like www.domain.com/home) this will have to cause another permanent redirect. So in essence the process will look like this:
REQUESTING: http:// www.domain.com
SERVER RESPONSE: HTTP /1.1 301 Redirect
1) Redirecting to: http:// www.domain.com/pages/home.aspx
SERVER RESPONSE: HTTP /1.1 301 Redirect
2) Redirecting to: http:// www.domain.com/home
SERVER RESPONSE: HTTP/1.1 200 OK
Is this how the URL Rewrite Module really works? I would have thought that it would not have to create another redirect in order to create a more user friendly URL?
My second problem is this.... The redirect is happening on the same server. So here is essentially the situation:
www.old-domain.com
www.dev-domain.com
www.new-domain.com
The old-domain needs to be redirected to the new domain so we ran a test in order to see if the HTTP status codes were correct before going ahead with the project. So the developer redirected the dev-domain to the new-domain and the redirects look like this: (The developers comments in italic below)
REQUESTING: http:// www.dev-domain.com
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
1) Redirecting to: http:// www.new-domain.com/
SERVER RESPONSE: HTTP/1.1 302 Redirect
2) Redirecting to: http:// www.dev-domain.com/Pages/home.aspx
SharePoint’s alternate access mappings causes this to happen and there is no way around this.
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
3) Redirecting to: http:// www.dev-domain.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
4) Redirecting to: http:// www.new-domin.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 200 OK
The developer states the reason for redirecting back to the dev-domain then back to the new-domain is because of SharePoint's alternate access mappings and there is no way around this. Is that entirely true?
Any assitance at all will be GREATLY appreciated!
Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.
I understand that most of the languages support server side redirects (asp.net: Response.Redirect, PHP: header( 'newpage' ) ; ). You could also do a redirect with JavaScript (window.location.href="newLocationURL").
When would you choose one over the other ?
With respect to ASP.net/IIS7(app pool in Integrated mode,enable 32 bit apps=false), I noticed that even when the page has a 302 header, the whole page body is sent to the client side.
And I believe this is not the case with PHP, only headers are sent ? To quote
Redirect on client side means following steps:Client-side -> Server-side -> Client-side -> Server-side -> Client-side.
Redirect on Server-Side means:Client-side -> Server-side -> Client-side (headers only)* -> Server-side -> Client-side.
Is there a W3C standard or server side redirect implementation differ from one web server technology to another ?
Edit: I am only concerned about Response.Redirect (in asp.net) and not server.transfer, at least for this discussion
The JavaScript example is actually not a redirect. There's no means of a 301/302 response. It is just a simple request which happens during a certain Javascript event long time after the page is arrived. If you do this during page load, then it would have more overhead than a real redirect and it would not work on JS-disabled browsers as well.
Redirects are to be initiated from the server side with a 301/302 response. All webapp languages/frameworks defaults to 302. You can usually make it 301 by adding one extra parameter or code line which instructs that. The benefit of 301 is by the way that the particular request won't be indexed (anymore) by the searchbots.
In ASP.Net, there is an important distinction between two kinds of server-side redirects. They are Response.Redirect and Server.Transfer.
If you call Response.Redirect, that entails two round trips to the server. On the first call to the server, the server response directs the browser to request the next page. Requesting that next page constitutes the second round trip to the web server.
If you use Server.Transfer, there is only one round trip. Therefore, there is much less network traffic. However, there is a limitation to using Server.Transfer, which is that the target page has to be on the same web server. That is, you can't Server.Transfer from your web app to www.Google.com. But you can Response.Redirect to it.
There are other details involved with using either of these approaches which you would want to research before using them. However, I believe that it is significant in the context of this question to note that in any language, Response.Redirect may result in much heavier network traffic than is really necessary.
It really depends on where you decide that you need to redirect. If it is server side code that determines that you have to redirect, then it is server side code that issues the redirect command. If you can decide client side that a redirect is needed, then do it from the client code.
It is probably more efficient from client side, since you avoid a the back-and-forth of the server side redirect thing..