Quicker Way To Hide Ref?
- Thread starter aim high
- Start date
- Status
hm. i just looked up double meta refresh and noticed that it may not always work and to have the second url as your homepage. that wouldn't be to good if you were using ppc though. i guess thats the price you pay for blanking referrers?
I remember us having a huge thread about this at one point, and I think we found out that if not a javascript redirect (and that should always be the first option) that a double meta refresh with each refresh set at 2 or 3 seconds would always do the job from what we tested. We should dig that thread up.
hm. why would a javascript redirect not work? is it because some people have scripts disabled?
Why not? Yes, because they have javascript disabled, it's a small amount of people but you still need to get them off your page. Found an article by SlightlyShady:
Controlling Your Referer, and Hiding Your Traffic Sources : Slightly Shady SEO
Should be of use.
The problem is that the referrer header is set by the browser, not by the referring site, and different browsers have different behavior around referrer headers -- and some browsers' behavior is actually inconsistent.
PHP redirects are 301/302 redirects, and thus should preserve referrer -- i.e. if Google sends the user to a 301, and it sends the user to the destination site, the destination site will receive Google as the referrer. I say "should" because, once again, browsers are different and inconsistent, but that's the spec behavior.
Meta refresh behaves differently between browers. On IE, I believe a meta refresh with a time of <3 seconds will preserve the referrer, while >3 seconds will send the refreshing site as the referrer. On Firefox, Meta refresh will usually send a blank referrer -- on one hand, this doesn't give away the source, but on the other hand, it may be suspicious (it made CJ ask what the hell I was doing.) To the Googlebot, a meta refresh <1 sec is considered a 301, while >1 sec is a 302, but both are followed.
JavaScript refresh should send the site with the script as the referrer, but sometimes sends blank, once again, depending on the browser. It shouldn't ever leak the true referrer, though. On the other hand, though, JS refresh is invisible to crawlers, so this is a bad idea in any SEO scenario -- the linking page will not pass the link to the real destination.
If site X iframes a destination, that will always pass site X as the referrer. Of course, the landing page will sometimes break the frame, but that usually doesn't matter overmuch.
PHP redirects are 301/302 redirects, and thus should preserve referrer -- i.e. if Google sends the user to a 301, and it sends the user to the destination site, the destination site will receive Google as the referrer. I say "should" because, once again, browsers are different and inconsistent, but that's the spec behavior.
Meta refresh behaves differently between browers. On IE, I believe a meta refresh with a time of <3 seconds will preserve the referrer, while >3 seconds will send the refreshing site as the referrer. On Firefox, Meta refresh will usually send a blank referrer -- on one hand, this doesn't give away the source, but on the other hand, it may be suspicious (it made CJ ask what the hell I was doing.) To the Googlebot, a meta refresh <1 sec is considered a 301, while >1 sec is a 302, but both are followed.
JavaScript refresh should send the site with the script as the referrer, but sometimes sends blank, once again, depending on the browser. It shouldn't ever leak the true referrer, though. On the other hand, though, JS refresh is invisible to crawlers, so this is a bad idea in any SEO scenario -- the linking page will not pass the link to the real destination.
If site X iframes a destination, that will always pass site X as the referrer. Of course, the landing page will sometimes break the frame, but that usually doesn't matter overmuch.
PHP redirects will NOT cloak the referrer.
The best way I've found is to meta redirect through a secure server (HTTPS), as long as your destination is a NON-SECURE page. Going from HTTPS to HTTP (through a meta redirect, not a 301 redirect) will completely STRIP the referring URL (blank).
The best way I've found is to meta redirect through a secure server (HTTPS), as long as your destination is a NON-SECURE page. Going from HTTPS to HTTP (through a meta redirect, not a 301 redirect) will completely STRIP the referring URL (blank).
https will strip the referrer with no overhead in terms of browser speed (encryption is a tiny, tiny overhead).
That's a 301 or 302 redirect just like PHP, which will NOT strip the referrer.
I just tested this out yesterday, and a simple 301 redirect through HTTPS will not strip the referrer. To make sure that it strips, you need your landing page on HTTPS or do a meta refresh.
HTTPS will pass on the referrer if you're going https to https, but I believe that's only within the same domain. I don't have a second https domain to test it on, though...
So...lemme get this straight...
You need separate HTTPS domains for both your Tracking program and LP for it to hide the referrer?
And is there a downside to using this method other than you have to buy SSL certs for every new niche domain you use?
using https to a nonhttps destination.. how to you avoid the "leaving secure destination" warning popup
No - sorry my post was confusing. You're able to use a single host for SSL trafffic - for example, my landing pages are at landingpage1.com and landingpage2.com. Traffic goes through https://mysecureredirect.host/whatever (so I don't need a new cert each time) - it must be a meta refresh. That will blank the referrer as long as the final destination is a non-secure (HTTP) page.
If my final destination is a secure (HTTPS) page, the referrer WILL be passed on. However, if you don't mind your meta refresh page appearing as the referrer, you're fine - the original landing page is hidden.
Most browsers don't have that warning enabled by default, to the best of my knowledge...
There's no way for you to prevent those warnings, except just not to use https.
not for everything. safari on OSX still passes the referrer when coming from an https site. it's practically impossible to really even block the source. there's always gonna be some strange oddball browser that screws up and reveals the referrer.
- Status