Forum Moderators: Robert Charlton & goodroi
Blocking our current shopping cart is not really a solution for https?
And is it worth the hassle?
The prefered setup (as at the git go) is to have the cart on its own subdomain with fully specified links back to the site. Then a robots.txt on the sub domain removes the cart from being seen by the bots.
The placing of the cart on its own subdomain means that the port never has to be opened on the primary domain.
There can then be no way for anybody to ever get a https: url to respond on the primary domain.
This situation is exactly like the www vs non-www issue done correctly from the begining it just could not happen.
However once it is out of the box you have both do a proper (as in working correctly) fix and the resulting cleanup.
[edited by: theBear at 5:45 pm (utc) on Jan. 10, 2007]
My question is, is it worth the hassle of changing into a sub domain?
I would do that only as a very last ressort, but try less invading techniques first, like forcing a redirect from https to http on a per page basis, if your pages are dynamic.
Check on every page if it was called as https -- or not, and 301 redirect it if needed -- by adding something like the following at the top of every page (untested PHP example, have seen this a few days ago elsewhere, but can't remember where).
if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS']=='on')) {
$thisurl = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
header("Location: $thisurl");
exit;
}
Kind regards,
R.
So Far, (keeping my fingers crossed), the detect port of request & then re-write for the robots.txt I did has so far had no negative effect. I believe my workaround is functioning correctly. I would think that if there was a problem with confusion of the http & https spidering of the site, I would have seen pages dropping by now. I still have duplicate supplemental https pages listed (when I really search for them), I am waiting for them to drop out. New pages I have added have been spidered & added to the SERPs but I still consider what I did a workaround, and I will at some point correct the setup & use a subdomain for my SSL checkout. I am not promoting what I did as a solution to others, it is just a workaround until I can do it right.
I was kidding when I asked if you were looking at my site & using it as an example, altho it certainly fits your description of how it was done wrong.
Back to Watching
WW_Watcher
I don't know about calling it wrong.
I think I said I just didn't want to leave it up to the folks at the 'plex getting the robots.txt files confused.
I'd rather play that one in a lot safer manner.
For some reason, I'm risk adverse when it comes to automated systems. I just see something that can replicate the same error very very very fast. That happens when you become an aged bruin.
The "Wrong" part was referring to me being clueless & built my site with the HTTPS & HTTP all on the same domain, not having separated out the HTTPS to a subdomain. It fits the description of the sites you had seen where the shopping cart had https links that caused the start of spidering the site via https.
I do not consider the re-write of the robots.txt wrong, it appears to work great, but for many reasons(including the possible risk of confusion of the contents of the robots.txt), it is not the right way to do it. So, I will not recommend it to others at this point.
IMHO as long as G does not consider http & https as the same entity, then my workaround should work.
Back to Watching
WW_Watcher
