Jules Webb said
1 year, 2 months ago: @jasonwiser @hjelliott @amyhallbiz
I enlisted the help of experts-exchange.com and with the assistance of DrDamnit I can report the following
RE: Gplus.mydomain.com vs mydomain.com/Gplus
From Google’s or an SEO standpoint, it makes no difference.
From a users standpoint it probably doesn’t either. Personally I would think that users who sees the link mydomain.com/gplus are more likely to expect to see a page on mydomain.com about gplus, not be redirected to a google plus profile. I guess it depends on how familiar or technically sophisticated a user is. And if you are adding this info to print medea, say a business card I think that gplus.mydomain is a much more attractive url than mydomain.com/gplus.
Ultimately since it doesn’t have an impact on search engines or SEO it’s up to each person to decide what they want.
RE 301 vs 302
gplus.to is using a 302 –but just because they use it, doesn’t mean it’s right. They may use it because they allow users to edit their links.
The ONLY reason to use a 302 instead of a 301 is if the url (address) is going to change. Since in this situation we’re discussing a vanity url using our own domain I think it’s fair to assume that it’s intended to be permanent.
Conclusion: use 301 unless you are planning on changing your redirect all the time. Then, use a 302. But for SEO, the 301 is better because it is cache-able —302′s are only cacheable if indicated by a Cache-Control or Expires header field.
————————————
Cite: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
- Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.- Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
——————————
