I just moved my blog to https and, of course, all the facebook shares counters are now reset to 0.
I've spent several hours reading stuff online and I got the solution to point the og:url tag to the old urls (with http instead of https).
It worked for a day but now all the counters are back to 0.
The strange thing is that if I check the urls (both with https and http) with the open graph debugger it returns me 0 shares for both the urls!
I really don't know what to do! Is there a way to have back the counters of the http-version of the urls? Or, as an alternative, is there a way to sum the two counters?
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
Facebook treats HTTP and HTTPS as two different URLs and therefor two different Open Graph objects, even if the rest of it is the same.
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
And that's your mistake ... You need to keep the old HTTP URLs available for the FB scraper to read the OG meta data from; if you redirect the scraper to the HTTPS version as well, then it concludes that the HTTPS versions was the actual correct URL for this piece of content - and therefor you have just undone what you tried to do by having og:url point to the old HTTP address.
See https://developers.facebook.com/docs/plugins/faqs#faq_1149655968420144 for more details.
The scraper can be recognized by the User-Agent request header it sends - see https://developers.facebook.com/docs/sharing/webmasters/crawler
(How to exclude clients that send a certain user agent from redirection via .htaccess is something that should be easy enough to research.)
Related
I found that anybody show their page to user, then 302 redirect to my site,
I want stop it.
I thought there would be referer in request header, but didn't!
I tested this in chrome72.0.3626.121 and ie11, and use fiddler to catch Request,
there have no referer header in all request.
And my server side code can't see referer too.
How can I stop 302 redirect to my site??
It's possible these days for sites to disable adding a referrer when a user follows a link. This is a privacy feature.
The result of sites using this feature is that you can't tell if:
A) A user opened your site directly from the addressbar
B) A user came to your site from somewhere else.
If you could tell the difference, it means the privacy feature is not working. Your only option is to block anyone with no referrer header, but then you might block a lot of other users as well.
There is one other common reason for this though, if you are running an insecure (http) site and you are being linked from secure (https://) site. It might be possible to get the referrer back in this case by upgrading your site to https.
Following the instructions given by google folks, I added https support to our blog.
Nginx, behind the scene redirect everything non http to https, proxied to a ruby on rails app.
Everything seems to work quite well but facebook counters appears now buggy.
If you look the source of this page : https://milesandlove.com/argentine/le-fitz-roy
I added a lot of og meta tags :
<meta property="og:url" content="https://milesandlove.com/argentine/le-fitz-roy"/>
<link rel="canonical" href="https://milesandlove.com/argentine/le-fitz-roy"/>
And the share button :
<a class="addthis_button_facebook_like" fb:like:layout="button_count" fb:like:href="https://milesandlove.com/argentine/le-fitz-roy"></a>
Note that even if its a add_this button, it would be exactly the same result with the official facebook one.
The weird thingis since nobody like the page, it kept showing the old count . Since a new person came and like the page, it suddenly reset the counter to 0 !
Is the count definately lost ?
Why Facebook is protocol aware ?
I read that a tricky solution whould be to serve a http:// page to the facebook
crawler. Is it the only solution ?
Essentially you've changed your URL - you might have to contact Facebook in order to "migrate" your likes (if that is even possible).
It is 100% possible to serve totally different content on the same domain with different protocols just like http differs from ftp, http can differ from https. I would say that this is expected behavior.
I don't think that this is a "tricky" solution. There are many cases in which you would want a crawler to see slightly different content from a regular user in a browser. You could set this up to only respond to Facebook by using their specified IP addresses mentioned on this page.
Facebook will reset the likes count on your ages when you move to https:// and there's no way around this. I have a 301 redirect on the old URL and Facebook doesn't follow it. It will not keep the old likes and it will treat https:// domain as a separate page. Which is bs really! I don't know of a single site that serves different content on http:// and https://. So, there's no solution to this issue at this stage.
I tried to find out this, and got that http://www.google.com/ncr uses 302(or 301) redirections(not sure if it really is).
and i also got that, the server side redirections(301 and 302) will not change the original referer, i.e. if i visit http://www.google.com/ncr directly, then the request goes to google.com, but nothing in the header can show that i come from http://www.google.com/ncr.
so i wonder how google do this.
People do this very often with servlets. The servlet would detect a certain pattern and issue a redirect to a conglomerated url. A redirect is directed at the browser. It's like the browser has activated/clicked on a new link.
It is like you entered google.com/abc on the url bar and then entered google.com on the address bar after that. Due to privacy issues, the browser does not let the server know what previous URL it has visited.
Of course, if you are on the same session, going to the same site, google would have both server side and client side cookies tracking you that you just came from another google url. If were a web service provider, I Would certainly exploit knowing your browsing history.
So that, due to your browsing history www.whatever. com would redirect to different pages for different users or sessions.
Addendum:
"Due to privacy issues, the browser does not let the server know what previous URL it has visited." is not quite correct.
The more complete spec is
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
Another reason why google forcing us to use https benefits us.
Redirect flow of non-secure http
Let's say we have
URL A has a link goto B with leads to URL B.
URL B is a redirect to URL C
The server of URL C will see the referer as URL A, not URL B. That is, the browsers will set the referer to URL A.
Redirect with cookies
I believe you should be able to include a setcookie header on a 30x redirect. I have not tried it so I do not know which browser will ignore or honour it.
BTW
I have great doubts that my answer is satisfactory for your question. I personally feel it is incomplete and I hope some one comes up with a better answer and you should choose that as the answer. In fact, I think you should unchoose this as the answer so that your question gets back into the pool of unanswered questions. Sorry.
I've got half a dozen legacy dynamic URLs and it turns out redirecting them all will require 18 Rewrite directives in my .htaccess file - that seems messy to me.
What I can do however, is redirect all of them to my new start page with a single Redirect directive. It's a tiny site and all the pages people might come in from via google searches are really easily findable from the start page so I'd like to do that however...
I'm worried this might kill the site's modest (but worth maintaining) page rank as several URLs would then be resolving to the same URL and content.
Does anyone know if this would be the case, and if so, if there are strategies to avoid that other then not implementing the above?
Thanks!
Roger.
As long as you do 301 Redirects (permanently moved) vs 302 Redirects (temporarily moved), then all the accumulated page rank from your dozen legacy URLs will transfer to the new url you are redirecting to.
So you will not "lose" the pagerank, it will simply be transfered over to the new URL.
The important thing is to ensure it's a 301 Redirect.
We are migrating to a Sharepoint solution and our urls are changing slightly.
Are most RSS readers able to follow redirect links without breaking the feed and making an update manually?
Most of the documentation I'm reading says that this will work for major RSS readers.
I have read in some places that a lot of RSS readers will treat a 301 as a temporary redirect and not update its stored url. Any truth to this?
Assuming you are using a 301 redirect, I would say yes, since any reader worth its salt is built on a compliant HTTP library which will honor the 301 status code and follow the redirect.
Of course, it's not that hard to test with the reader of your choice.
Pretty much every RSS reader - major or minor - will update the feed URL when it encounters a 301 redirect.
In my (limited) experience, most applications will ignore the "permanent" part of a permanent redirect and execute the same logic they would use for a temporary redirect.
It may be necessary to make its site velindekserede about. What to do so to preserve PageRank, link popularity and traffic?
As I understand it, so the solution is called a 301 redirect. It tells search engines that the URL has been permanently moved. How a redirect should be done in a special way. At this link there are different options depending on what kind of server technology you use:
http://www.webconfs.com/how-to-redirect-a-webpage.php
I just tried it in practice. I use PHP itself on all my sites, so I used the PHP instructions:
I ripped all my old page for tags and content and put the small code snippet on the page. Prisoners of the new URL for the page, and saved it. Tested the page by typing the old URL and then redirects worked. To be absolutely sure that redirects are search engine friendly, I used this "Search Engine Friendly Redirect Checker":
http://www.webconfs.com/redirect-check.php
There no disagreement about how well the 301-redirect is working and whether it can transfer an entire site to a new domain (http://www.webmasterworld.com/link_deve ... 135964.htm), but people's experience says that it is good enough. You just make sure that the new URL has the content as the old page had