I understand the og:url meta tag is the canonical url for the resource in the open graph.
What strategies can I use if I wish to support 301 redirecting of the resource, while preserving its place in the open graph? I don't want to lose my likes because i've changed the URLs.
Is the best way to do this to store the original url of the content, and refer to that? Are there any other strategies for dealing with this?
To clarify - I have page:
/page1, with an og:url of http://www.example.com/page1
I now want to move it to
/page2, using a 301 redirect to http://www.example.com/page2
Do I have any options to avoid losing the likes and comments other than setting the og:url meta to /page1?
Short answer, you can't.
Once the object has been created on Facebook's side its URL in Facebook's graph is fixed - the Likes and Comments are associated with that URL and object; you need that URL to be accessible by Facebook's crawler in order to maintain that object in the future. (note that the object becoming inaccessible doesn't necessarily remove it from Facebook, but effectively you'd be starting over)
What I usually recommend here is (with examples http://www.example.com/oldurl and http://www.example.com/newurl):
On /newpage, keep the og:url tag pointing to /oldurl
Add a HTTP 301 redirect from /oldurl to /newurl
Exempt the Facebook crawler from this redirect
Continue to serve the meta tags for the page on http://www.example.com/oldurl if the request comes from the Facebook crawler.
No need to return any actual content to the crawler, just a simple HTML page with the appropriate tags
Thus:
Existing instances of the object on Facebook will, when clicked, bring users to the correct (new) page via your redirect
The Like button on the (new) page will still produce a like of the correct object (but at the old URL)
If you're moving a lot of URLs around or completely rewriting your URL scheme you should use the new URLs for new articles/products/etc, but you'll need to keep the redirect in place if you want to retain likes, comments, etc on the older content.
This includes if you're changing domain.
The only problem here is maintaining the old URL -> new URL mapping somewhere in your code, but it's not technically difficult, just an additional thing to maintain in the future.
BTW, The Facebook crawler UA is currently facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
I'm having the same problem with my old sites. Domains are changing, admins want to change urls for seo etc
I came to conclusion its best to have some sort uniqe id in db just for facebook - from the beginning. For articles for example I have myurl.com/a/123 where 123 is ID of the article.
Real url is myurl.com/category/article-title. Article can then be put in different category, renamed etc with extensive logic for 301 redirects behind it. But the basic fb identifier can stay the same for ever.
Of course this is viable only when starting with a fresh site or when implementing fb comments for the first time.
Just an idea if you can plan ahead :) Let me know what you think.
Related
So, we run a news site and the URLs for specific articles might change after the article has been published (the URL usually contains the article title).
To keep track of Facebook shares even when the URL changes, we've add the og:url property with the unique URL for the article (which is basically our domain, followed by the article ID).
The problem is, this unique URL redirects to the article page, so when I share the "pretty" article URL, I get a redirect loop.
Any ideas on how to workaround this issue?
Thanks!
Well, if you're setting the og:url parameter to anything other than the canonical URL for that content, you're misusing it.
The og:url tag tells Facebook where to go for the canonical metadata for a URL - if you're then redirecting elsewhere from that URL, it wasn't really the canonical URL - you should have set the og:url value to wherever is at the end of the redirect cycle, and put the article metadata there
if you need to track specific placements or clicks of the like button and the referral traffic from those, there's a ref parameter you can use for that which is passed back to you in the referral traffic, it's documented here: https://developers.dev.facebook.com/docs/plugins/like-button/#faqref
I understand the og:url meta tag is the canonical url for the resource in the open graph.
What strategies can I use if I wish to support 301 redirecting of the resource, while preserving its place in the open graph? I don't want to lose my likes because i've changed the URLs.
Is the best way to do this to store the original url of the content, and refer to that? Are there any other strategies for dealing with this?
To clarify - I have page:
/page1, with an og:url of http://www.example.com/page1
I now want to move it to
/page2, using a 301 redirect to http://www.example.com/page2
Do I have any options to avoid losing the likes and comments other than setting the og:url meta to /page1?
Short answer, you can't.
Once the object has been created on Facebook's side its URL in Facebook's graph is fixed - the Likes and Comments are associated with that URL and object; you need that URL to be accessible by Facebook's crawler in order to maintain that object in the future. (note that the object becoming inaccessible doesn't necessarily remove it from Facebook, but effectively you'd be starting over)
What I usually recommend here is (with examples http://www.example.com/oldurl and http://www.example.com/newurl):
On /newpage, keep the og:url tag pointing to /oldurl
Add a HTTP 301 redirect from /oldurl to /newurl
Exempt the Facebook crawler from this redirect
Continue to serve the meta tags for the page on http://www.example.com/oldurl if the request comes from the Facebook crawler.
No need to return any actual content to the crawler, just a simple HTML page with the appropriate tags
Thus:
Existing instances of the object on Facebook will, when clicked, bring users to the correct (new) page via your redirect
The Like button on the (new) page will still produce a like of the correct object (but at the old URL)
If you're moving a lot of URLs around or completely rewriting your URL scheme you should use the new URLs for new articles/products/etc, but you'll need to keep the redirect in place if you want to retain likes, comments, etc on the older content.
This includes if you're changing domain.
The only problem here is maintaining the old URL -> new URL mapping somewhere in your code, but it's not technically difficult, just an additional thing to maintain in the future.
BTW, The Facebook crawler UA is currently facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
I'm having the same problem with my old sites. Domains are changing, admins want to change urls for seo etc
I came to conclusion its best to have some sort uniqe id in db just for facebook - from the beginning. For articles for example I have myurl.com/a/123 where 123 is ID of the article.
Real url is myurl.com/category/article-title. Article can then be put in different category, renamed etc with extensive logic for 301 redirects behind it. But the basic fb identifier can stay the same for ever.
Of course this is viable only when starting with a fresh site or when implementing fb comments for the first time.
Just an idea if you can plan ahead :) Let me know what you think.
I understand the og:url meta tag is the canonical url for the resource in the open graph.
What strategies can I use if I wish to support 301 redirecting of the resource, while preserving its place in the open graph? I don't want to lose my likes because i've changed the URLs.
Is the best way to do this to store the original url of the content, and refer to that? Are there any other strategies for dealing with this?
To clarify - I have page:
/page1, with an og:url of http://www.example.com/page1
I now want to move it to
/page2, using a 301 redirect to http://www.example.com/page2
Do I have any options to avoid losing the likes and comments other than setting the og:url meta to /page1?
Short answer, you can't.
Once the object has been created on Facebook's side its URL in Facebook's graph is fixed - the Likes and Comments are associated with that URL and object; you need that URL to be accessible by Facebook's crawler in order to maintain that object in the future. (note that the object becoming inaccessible doesn't necessarily remove it from Facebook, but effectively you'd be starting over)
What I usually recommend here is (with examples http://www.example.com/oldurl and http://www.example.com/newurl):
On /newpage, keep the og:url tag pointing to /oldurl
Add a HTTP 301 redirect from /oldurl to /newurl
Exempt the Facebook crawler from this redirect
Continue to serve the meta tags for the page on http://www.example.com/oldurl if the request comes from the Facebook crawler.
No need to return any actual content to the crawler, just a simple HTML page with the appropriate tags
Thus:
Existing instances of the object on Facebook will, when clicked, bring users to the correct (new) page via your redirect
The Like button on the (new) page will still produce a like of the correct object (but at the old URL)
If you're moving a lot of URLs around or completely rewriting your URL scheme you should use the new URLs for new articles/products/etc, but you'll need to keep the redirect in place if you want to retain likes, comments, etc on the older content.
This includes if you're changing domain.
The only problem here is maintaining the old URL -> new URL mapping somewhere in your code, but it's not technically difficult, just an additional thing to maintain in the future.
BTW, The Facebook crawler UA is currently facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
I'm having the same problem with my old sites. Domains are changing, admins want to change urls for seo etc
I came to conclusion its best to have some sort uniqe id in db just for facebook - from the beginning. For articles for example I have myurl.com/a/123 where 123 is ID of the article.
Real url is myurl.com/category/article-title. Article can then be put in different category, renamed etc with extensive logic for 301 redirects behind it. But the basic fb identifier can stay the same for ever.
Of course this is viable only when starting with a fresh site or when implementing fb comments for the first time.
Just an idea if you can plan ahead :) Let me know what you think.
I recently changed domain name for my site and migrated my content. Most URLs from the old site use a 301 redirect to the new site, as you would guess.
In an effort to retain FB like and comment data, I kept the og:url property set to the old URL, since it is the original and canonical identifier in Open Graph. I implemented in August, and it was working properly, with previous like data retained. Now it is not working and showing previous like data, and fails in the URL Debugger.
Here is an example from the new site:
http://seattle.findwell.com/million-things-to-do-seattle/washington-brewers-festival-2011
In URL Debuggger, it now returns this error:
There was an error in fetching the object at URL 'http://seattle.findwell.com/million-things-to-do-seattle/washington-brewers-festival-2011/', or one of the the URLs specified via a redirect or the 'og:url' property including one of http://www.hometalkin.com/seattle/million-things-to-do-seattle/washington-brewers-festival-2011/.
Nothing has changed in my OG tags. Has something changed with canonical URL in open graph that causes it to fail when a redirect is in place?
This page:
http://seattle.findwell.com/million-things-to-do-seattle/washington-brewers-festival-2011
has this og:url:
<meta content="http://www.hometalkin.com/seattle/million-things-to-do-seattle/washington-brewers-festival-2011/"
property="og:url" />
but when you actually go to (in fact - when Facebook crawler tries to go to) this URL from og:url the site redirects you back to:
http://seattle.findwell.com/million-things-to-do-seattle/washington-brewers-festival-2011/
This is a circular reference.
In order to fix it you need to change your og:url to:
http://seattle.findwell.com/million-things-to-do-seattle/washington-brewers-festival-2011/
I actually had a very difficult time with this when I was first starting out as a developer.
I made a tool for this exact purpose -- as I thought it might be helpful to others:
Facebook/Open Graph Like Button Generator
It generates (and stores) the open graph tag(s) so you don't need to put them in your page and the 'Redirect URL' tells it where to send all the traffic.
It detects the Facebook bot/scraper too so it won't interfere with anything :)
Good luck
I had exactly the same problem.
I have changed my website url and I have over 40.000 radios with fb likes and comments.
Example:
http://www.radioways.com/fr/radio/nrj.html
to
http://www.radioways.fr/radio/nrj.html
I spend days and days reading and checking the forum and I did not find the answer...
Here is what to do:
1. In the og canonical, you need to put your old website url
2. In the Iframe url, you can put both. The result of the likes, will be the addition of the likes of the ogcanonical + the likes of the Iframe
An this will not work (and this is why I spent so much time USELESS) untill you validate those setup with FB
Best regards.
We are working on a facebook-app with lots of dynamic pages. As the app is embedded in a tab on a facebook page, the urls contain a get-parameter to address the correct tab/app. We want to implement like- and send-buttons for several pages within our app, but facebook seems to dump all get-parameters from urls within facebook. As the result all like- and send-buttons point to the facebook-page itself instead of the tab.
Does anybody now any workaround? We already tried redirects via an external sefor facebook urls only.rver but facebook seems to evaluate the links on click of the like-/send-button (and seems to follow all sort of redirects).
UPDATE:
Here is an example of a problematic url:
https://www.facebook.com/smartmobil.de?sk=app_171502639574871
UPDATE:
The problem seems to be independant of url get-parameters. It seems that the like-button does not work with any url starting with www.facebook.com
When used in a like-button everything behind the ? will be dumped. This seems to happen for facebook urls only.
Best workaround so far is to point your like buttons at external (non-facebook canvas) urls.
To make this work, you need to do some conditional redirecting to get the user back into your canvas URL. You can either use a client side javascript redirect:
<script>
window.location = 'http://apps.facebook.com/yourcanvasname/foo/bar';
</script>
Or you can do a server side redirect based on the useragent string. Basically, if the useragent contains 'facebookexternalhit' then render a basic HTML page containing OG tags, if not, redirect to the canvas URL.
Doing this means the Facebook sharescraper/linter won't follow any redirects back to the canvas URL, but any user that arrives at your URL will get back to Canvas.
i'm too searching for a solution to control the custom page tab's content through a get parameter (app_data). I still don't have a solution but here at least the reason why all www.facebook.com links are srtiped out of get params. Here at bottom the developer explains why.
Unfortunately I don't think what you are trying to do is possible. Posting a like programmatically requires you to specify a Facebook content ID or alias. This won't work for you because tabs to not seem to have an exposed content ID of their own, and instead use the Page's content ID with an additional parameter which you can't use with the graph.
Liking external links and other content that does not have an ID programmatically is prohibited. With an external URL, the first like of an unrecognised URL creates a new Facebook page for those likes to be represented on (which is the issue I've given up trying to fight), but presumably the presence of your Page's content ID alias (www.facebook.com/smartmobil.de) in the url is making Facebook choose you page rather than creating a new one.
The only suggestion I can think of this late at night is to target an external URL that performs a redirect via Javascript, rather than on the server, but Facebook may be wise to that too and I'm afraid I'm going to bed rather than testing it :)