Can I leave off HTTP/HTTPS in a canonical tag?

[Andy.Drinkwater]

Example of what they would like to do

That would be a no-no Shawn. If you are running over SSL, then you need to canonical back to the https version of the page. If you don't, you will end up with errors on the page (yellow warning triangle) and trust issues with Google. What they would like to do is canonical to a malformed URL which it could interpret as a file.

Try going to any URL and just entering it as //www.domain.com

-Andy

[PatrickDelehanty]

Hi again

To be clear, I think this would populate http://www.domain.com//www.domain.com as the where the canonical should be attributed to.

Hope this makes a bite more sense. Good luck!

[Shawn_Huber]

Thanks for the answers, all of which I've passed on to them.

They have attempted this on a page and have not seen any errors or issues as of yet which is problematic for me in the sense of if I cannot show where any issue results by them taking shortcuts, they will not necessarily listen to my feedback.

Here is the URL that they have left off the protocol in the canonical

http://www.alaskaair.com/content/deals/flights/cheapest-flights-to-hawaii.aspx.

I use the Chrome extension Canonical which doesn't give me the icon indicating that I am not viewing the preferred URL. When I use HTTPS and view source it looks the same as it does with HTTP. Sometimes there are parameters in the URL like ?INT=AS_HomePage_-prodID:SEO and even with HTTP missing from the canonical it still seems to work.

Since I cannot find any documentation against doing it this way I am getting strong resistance to declaring HTTP and then going back at some point when it moves to HTTPS and updating. Like I've stated above, they are using this for links and assets on the site since our site moves back and forth between HTTPS and HTTP depending on what the customer is doing and they have found leaving off the protocol it makes their life easier and limits the errors that Andy below mentions.

https://www.alaskaair.com/content/deals/flights/cheapest-flights-to-hawaii.aspx

[Shawn_Huber]

Thanks Andy, I posted a reply to the other response that ties into your comment here. On the page I listed above, there are not errors if I use HTTPS and the canonical doesn't declare anything. We have SSL certs, just haven't made the big switch yet.

[Andy.Drinkwater]

Well, if it works (which I didn't think it would!) then I guess that answers one question - and I ran that page through Screaming Frog just to confirm there are no issues and it does indeed canonical back to the https version of the page.

I just can't get out of the mindset that the format looks wrong. I haven't seen other instances of it done that way, and like you, have no documentation to suggest issues that might be caused.

Sorry I can't be of more help.

-Andy

[Shawn_Huber]

I know, and that's what sucks. It appears to work, but goes against what seems to be best practice and since I cannot find other instances to state one or the other it's hard not to follow their logic.

I just hope it doesn't screw up everything in the end. Thanks for the discussion.

[Andy.Drinkwater]

No worries Shawn. I also hope it doesn't cause issues down the line. Everything in me is screaming "Don't do it!"

Best of luck.

-Andy

[Everett]

Shawn,

My advice would be to canonical everything to the HTTPS version using an absolute path. That would be the best practice. I understand that is not what you're doing and you aren't getting any errors, but site-wide use of rel canonicals is something that can do more harm than good if a search engine misinterprets what you're trying to accomplish.

Either way, good luck and keep us posted.

[linklater]

Hey Shawn, did using an unspecified HTTP/HTTPS protocol work for you in the canonical and/or HREF-LANG? We are going through a transition to HTTPS as well, and have multiple systems with some URLs that are hard coded. Hoping this solution would work as a short-term fix, while we update these pages to use a new, more dynamic system.

[Shawn_Huber]

Now that our entire site is HTTPS, there does not seem to be any negative impact to our URL's by leaving off the HTTP protocol. If there was any traffic lost, it didn't seem significant as our reports did not indicate a decline. One year later, traffic through SEO is higher than before we implemented.

I personally agree with Everett, don't leave things to chance. I did require that the homepage did have HTTPS for the canonical though.  I felt massive panic attacks while we were going through the transition. However, if you are unable to convince your developers the importance of using an absolute path for canonical this did not seem to have a negative impact on our site.

I am glad that we didn't have any noticeable impact, but I am also glad that I didn't turn it into a bigger issue within our leadership team. Since we didn't see anything negative, it could've reduced my credibility within the business which would've had made it difficult for larger SEO problems.

BTW, we are still using relative canonical tags today. (except the homepage, that still has HTTPS)

[Everett]

That's good to know. Thanks for the update Shawn.

Since the initial discussion took place several Google reps. have publicly stated that there is no PageRank loss between redirects and rel ="canonical" tags. This seems to substantiate their claim.

The biggest issue with these is when giving conflicting instructions to user agents, such as a redirect to a page that rel canonicals back to the URL from which it was redirected, thus closing an infinite loop. For example, if you redirected from HTTP to HTTPS, but then the HTTPS version had a rel ="canonical" tag that was hard-coded to the HTTP version.

The above issue doesn't apply because you're redirecting from HTTP to HTTPs, which shows a relative path rel canonical tag for the HTTPs domain.

[linklater]

Very good to hear, thanks Shawn!  The goal is to use absolute canonicals, but for a period of time, we may have to use protocol relative.  The redirects in place should avoid any duplicate content issues, which seems to be the big landmine.