We're trying to build a share widget for referral links (links that are essentially short urls - a.b.com/uniqueCode, which redirects to a client website but goes through our service and lets us track them) - essentially someone needs to share their own affiliate url on Facebook.
The problem is Facebook seems to always resolve the url to the final destination, and doesn't display the url we pass in. I can't find any documentation on whether there's a way to prevent this or not. We've tried both with a 301 and 302 redirect, with no change. I've tried different urls to make sure we're not seeing the result of their url caching.
Is there a way to instruct Facebook (and Google Plus, Linkedin) to keep the referring link we provide?
You could try doing the redirect using Javascript.
Also, you might be able to do it by showing the social networks' crawlers different pages based on their useragent or IP or so – look into your webserver logs or so and check what happens there immediately after you've posted the link.
Related
I have a website that I want to share to facebook
https://pvp5.com/item/12057/Sakura-Transient-House
But when facebook fetch the url it always fetch the home url
https://pvp5.com/home
I have a screenshot to prove it. I also did a basic troubleshooting turning off my caching mechanism and website page rules. Why is this happening?
Why is this happening?
Because you explicitly said so, by specifying the Canonical URL as https://pvp5.com/home for all pages.
The canonical URL should be set to the individual URL of that article/piece of content you want to share.
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.
The Facebook OpenGraph debug tool is scraping the wrong page.
If I give it a full URL (pointing to an individual page on my site) that I want it to scrape, instead of scraping that page and finding its meta tags, it scrapes my site's main page and returns those meta tags (which are obviously wrong in this context).
The weird thing is, it will even find and scrape my site's main page even if it's not located at the root of my domain. For example:
I want it to scrape http://mydomain.com/myhomepage/specific_page.html
Instead, it scrapes http://mydomain.com/myhomepage/
This implies to me that the error must be a setting someplace, either on my site or on my Facebook App settings. Would the App settings do that? Redirect to whatever URL is set if a requested URL is a descendent of it?
The URL I'm requesting is not doing a 302 or anything - I can click the link from the FB debug tool even and it will take me to the appropriate page.
A few notes:
specific_page.html is not an actual file, it is routed through index.php using mod_rewrite in Apache's htaccess. I tried being specific with http://mydomain.com/myhomepage/index.php/specific_page.html and it did not work then either.
Another SO question led me to believe that the user-agent might be getting redirected if it doesn't allow cookies (as the Facebook web crawler does not) so I opened a fresh browser, disabled cookies, tried again, and I still reached the appropriate page.
As mentioned in the comments above, in your case this was due to an og:url meta tag, redirecting Facebook's crawler to that URL
In general, cases like this are usually the og:url tag, a HTTP redirect, or a canonical meta tag pointing at the 'other' / 'wrong' URL - Facebook's crawler follows those redirects looking for the final URL
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 :)
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.