HTTPS... external links update required?

[fashezee]

How many are going back to all your external links to painfully request a URL update?
Is it recommended?

[Robert Charlton]

fashezee - to clarify and make absolutely sure what question you're asking, I assume that you're talking about updating external inbound links from http to https after a protocol change. Is that correct?

Assuming that it is inbound backlinks and only backlinks you're asking about, I'd say that if you've used proper 301 redirection, it's not mandatory that backlinks be changed. If it were a change of domain name and not the protocol, getting some backlinks updated, IMO, would be advisable to provide a confirmation to Google that this is the same as the old site. But if the only change is http to https, I assume that Google would trust the 301s. You might want eventually to get some of the backlink protocols updated anyway, but that would not be my first concern.

There are likely other urls apart from backlinks referring to your site, everything from rel canonical elements to scripts and account IDs, that might contain the old http protocol but don't resolve into backlinks... and those do need to be checked out and changed, in many cases before launch. Using either root relative or protocol relative urls in your internal nav will help eliminate some mistakes.

I'll leave a comprehensive list of other urls to others... but the above is my take on the backlinks part of your question, if that's what you're asking.

[Wilburforce]

I haven't bothered. Most have changed now (about a year in), but 301s deal with the remainder, and it doesn't seem to make any difference to Google or any anyone else.

[robzilla]

It's such a small change, one that users won't notice, so I'm not going to bother anyone with it. Besides, I don't think it's even necessary, and in requesting the change you risk getting the link re-evaluated, and possibly removed. Let sleeping dogs lie ;-)

[fashezee]

@Robert: Yes, I was referring to inbound backlinks.
301s have worked seemless for us in in the past for inner pages; but we get a little paranoid when it comes to changing our homepage. Thanks for tips gents.

[cr1m]

Don't know how much we can trust Gary Illyes in this kind of questions, but he said "it's not worth it" (if redirects are implemented correctly) - [seroundtable.com...]

[Shaddows]

I posted this in the main thread, and cant be bothered to reformat it. Google says there is no need to change links, as 301s retain all link juice:

FAQs for all site moves with URL changes
...
Do I lose credit for links when I redirect to new URLs?
No, 301 or 302 redirects do not cause a loss in PageRank.
[support.google.com...]

And for added clarity, Google classifies the https move as a "site move with URL changes" per the above FAQ. Sources here:

Migrating from HTTP to HTTPS

If you migrate your site from HTTP to HTTPS, Google treats this as a site move with a URL change
[support.google.com...]

What is a site move?
...
2. Site move with URL changes
The page URLs change. For example:

The protocol changes — http://www.example.com to https://www.example.com
[support.google.com...]

[lucy24]

Don't forget your human users. Every redirect doubles the time before content starts showing up. For users on slow connections, that's a measurable lag. For users who pay for bandwidth, that's a few more bytes added to the total.

For that matter, it counts against your own bandwidth too; it's one more thing for your server to deal with. Why bother with an extra request-and-response set if you don't have to?

[eeek]

Every redirect doubles the time before content starts showing up.

I don't see that. A 301 redirect is very small and, at least on my servers, is handled rapidly.

[lucy24]

X nanoseconds to send request + Y nanoseconds to get response with content = X+Y nanoseconds

X nanoseconds to send request + Y nanoseconds to get 301 response + X nanoseconds to send new request + Y nanoseconds to get response with content = 2X+2Y nanoseconds

[Wilburforce]

Every redirect doubles the time before content starts showing up.

Well, yes, it doubles the time before the first GET is executed, but that isn't usually very long, and is negligible in comparison with overall load time.

Estimates of the average number of requests per page vary, but it is somewhere in the order of 100 or so. Even if we assume that each of these requests takes the same time to complete (and in reality a large image takes a lot longer than a small stylesheet, and every one of them takes longer than a redirect), we're only adding about 1% to overall load time. Even on a (slow) page-load time of 10s, that represents 100ms, or about a third of a blink: blink and you really will miss it.

Factor in typical content load-time (even on pages with fewer requests and small file-sizes) and you can safely ignore the effect of a single redirect. There are far greater speed savings to be made elsewhere.

[robzilla]

A redirect adds another roundtrip, so it depends on the latency between client and server. Mobile users are especially affected by this, as well as users with relatively poor internet connections. If you redirect to a different (sub)domain, you need to add another DNS lookup as well, but that won't be the case with HTTP > HTTPS. You'll want to avoid redirects whenever you can, but it's still not worth trying to get external links updated.

[Wilburforce]

You'll want to avoid redirects whenever you can

Yes, I didn't mean to suggest they should be used unnecessarily. With HTTP to HTTPS, however, there isn't really a more sensible option.

In that particular case, it is also worth bearing in mind that if SEs have reindexed and all internal links are OK, the only users affected by a 301 will be those coming from historical backlinks* (i.e. those to whom the OP's question applies), and even then - as the redirect will be cached - it will only affect the landing page on their first visit.

_{*Including bookmarks, but only the user can update these.}

[robzilla]

With HTTP to HTTPS, however, there isn't really a more sensible option.

Not really, no, but one could also look into HSTS [en.wikipedia.org] as an additional measure. Just know that there's no possibility of mixing HTTP & HTTPS or reverting back to HTTP after implementing that (and optionally getting on the browsers' preload lists).

[aristotle]

This is slightly off-topic, but I recently checked an old list of outlinks from a "links page" on one of my sites, in order to update the links to those sites that have recently switched to https.

Checking with Zenu, I discovered that some of them are using 302s instead of 301s to re-direct from http to https.

In other words, whoever implemented the switch to https on those sites used a 302 for the redirect to https.

I don't understand why anyone would do this, unless they thought they might have to revert back to http. The other question is how does google treat this.

[robzilla]

I've seen that happen with redirects set up by certain control panels, where they default to 302, perhaps to be "safe", so it's probably (and unfortunately) quite common.

I believe Apache also defaults to 302.

[lucy24]

I don't understand why anyone would do this

They probably didn't. The server doesn't distinguish between, for example, [R] and [R=302]; the same numerical response is sent out either way.

[aristotle]

Yes I know they have the same effect. But doesn't googlebot see the 302 instead of a 301? And if so, the 302 would imply that it's only a temporary redirect. And so isn't it possible that this could affect the site's rankings after the switch to https?

[robzilla]

I think lucy24 meant that when Apache sees the bare [R] directive, it defaults to 302. So [R] and [R=302] both return 302. If you want 301, you need to specify [R=301]. And yes, Googlebot will read the exact status code and act accordingly, as with 404 (Not Found) vs. 410 (Gone), for example.

[aristotle]

Well the question I've been trying to ask is -- Doesn't the use of a 302 imply that the switch to https is, or might be, only temporary? And if so, isn't it possible that this could hurt the site's google rankings after the switch?

[lucy24]

Doesn't the use of a 302 imply that the switch to https is, or might be, only temporary?

Yes, it kinda does imply that. But the underlying question is: did the site owner intentionally and explicitly return a 302? Or did they just say [R] (or equivalent on other servers), not realizing that this would default to 302? If you happen to be on good terms with any of those site administrators, you could ask. Otherwise there is no way to know.

[keyplyr]

I believe Apache also defaults to 302.

Not my Apache (2.2 ; Ubuntu)

[lucy24]

Not my Apache

Wha-a-a-a?

When you return a simple [R], or a Redirect without "Permanent", do you mean to say that your server sends it out as a 301? That's contrary to everything I have ever read in Apache docs.

2.2 on mod_rewrite (2.4 has identical wording in this section):

Any valid HTTP response status code may be specified, using the syntax [R=305], with a 302 status code being used by default if none is specified.

2.2 and 2.4 on mod_alias:

If no status argument is given, the redirect will be "temporary" (HTTP status 302).

[keyplyr]

oh

I thought robzilla was saying that if I write a 301 it defaults to a 302. My bad.

[lucy24]

Whew :)