Why non-canonical URL with a fragment identifier (#) is shared with a `_escaped_fragment_` query parameter? - facebook

I'm using Facebook's Share Dialog to share a URL like...
http://www.example.com/products/9-some-name#!23
In the HTML for that page, a different URL (also with a fragment identifier) is specified as the canonical URL, like
<link rel="canonical" href="http://www.example.com/products/9-canonical-name#!23">
<meta property="og:url" content="http://www.example.com/products/9-canonical-name#!23">
In my Facebook profile, the shared URL shows as
http://www.example.com/products/9-canonical-name?_escaped_fragment_=23
Is that a bug?
(I expected the shared URL to be posted as-is, i.e. not the canonical one, and without any transformation.)
UPDATE
After more investigation I realized this doesn't have anything to do with fragment identifiers. The essential problem is that the URL posted by Facebook in the user's profile is the URL in og:url, not the originally shared URL. And it seems that can't be changed (as I understand from a related question).

According to the documentation for sharing best practices on Facebook the the og:url should be a URL with no session id or extraneous parameters. All shares on Facebook will use the og:url as the identifying URL.
developers.facebook.com/docs/sharing/best-practices#tags

Related

Facebook sharer and parameters in url

I have a Wordpress page that needs a GET parameter in URL.
Depending on the id, it shows a different flipbook.
The problem is, when I share the link on Facebook, it crops the GET parameters (I checked with the Open Graph Debugger), so the page doesn't receive any parameter, thus there's no thumb showed.
I already tried encoding the URL with PHP.
So, two questions:
Is it possible to make Facebook recognize the GET parameters in URL?
If not, can I work out something with the .htaccess file, to make them appear like subpages? E.g. www.page.com/flipbook/?id=7 would become www.page.com/flipbook/7/
The problem was SEO Yoast was automatically writing the tag:
<meta property="og:url" content="www.page.com/flipbook/">
So Facebook was reading this and not the parameter.

Difference between rel="canonical" and og:url?

I'm having trouble understanding canonical URLs with regards to how search engines and Facebook seem to handle them.
My Google maps powered site allows visitors to use social media to request a gig in their country. One of the pages in question can be found at: http://izzy.nogig.in/
When a user clicks on their countries marker it gives them sharing options (twitter/facebook/etc), which when shared will share the URL specifically for that country, eg: izzy.nogig.in/usa? or izzy.nogig.in/spain? etc.
All of these countries in the URL amount to a lot of duplicate content so I use the following to point search engines to the page I want ranked:-
<link rel="canonical" href="http://izzy.nogig.in/_?"/>
For Facebook Likes to count towards each individual country I've set my Open Graph "og:url" as follows, eg:
<meta property="og:url" content="http://izzy.nogig.in/australia?" />
Now when I run a country-specific URL through the Facebook Object Debugger (eg. http://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fizzy.nogig.in%2Faustralia%3F) it shows the following:-
Response Code: 206
Fetched URL: http://izzy.nogig.in/australia
Canonical URL: http://izzy.nogig.in/australia
Mismatch og:url and canonical url:
og:url tag in the header is not the same URL as rel='canonical' link in the html.
The above error is what's confusing me. I know they're mismatched, but I thought this was the correct way to do this.
Everything in the debugger looks good to me (correct link, description, image etc for each country), and I can't change the rel="canonical" value to match my og:url as I need it pointing to a single page (country-less) for search engines.
I believe it is all working correctly. Should I just ignore the error from the debugger, or have I set this up incorrectly? I don't want "likes" for each country all disappearing and counting towards the rel="canonical" URL.
Many Thanks - Will
link rel="canonical" will be used by search engines where as og:url will be used by facebook
og:url basically tells the FB scraper "ignore anything on this page, and scrape this url instead"
More for Canonical link element: http://en.wikipedia.org/wiki/Canonical_link_element
Canonical urls refer to page content.
The target (canonical) IRI MUST identify content that is either
duplicative or a superset of the content at the context (referring)
IRI. rfc6596#3
Opengraph url refers to "object".
The canonical URL of your object that will be used as its permanent ID in the graph, e.g., "http://www.imdb.com/title/tt0117500/". ogp.me
So they may be different. For example, for multi-language websites, page for each language should have distinct canonical url, because content is different, but usually the same og:url for all languages, because they refer to the same object described in multiple languages.
On one of the sites I've developed I serve the page in more than one language, and provide links to allow the user to switch between one language and the other. So, my rel="canonical" will have the URL http://www.example.com/, whereas, within the code I update the og:url so that it is either http://en.example.com/ or http://fr.example.com/. That way when the user shares the page on Facebook, everything will appear on Facebook in the language they were viewing the page, which makes sense since most of the visitor's friends will likely speak the same language.
Regards.
I see no reason why og:url and canonical should be different. In both circumstances you're saying to either the search engine or Facebook what page you want to index or be displayed.

Facebook linter complains about multiple og:url, but there is only one

I have been trying to make sure my pages in my new blog are absolutely correct when it comes to integration with facebook etc. When I put my URL in the facebook linter at:
http://developers.facebook.com/tools/debug
And put: myurl.com?fbrefresh=true
It complains that there are 'More Than One OG URL Specified'. I've checked the source and there is only one og:url, I've also checked it from the bottom link on the linter page itself where there is 'Scraped Url: See exactly what our scraper sees for your URL' and again I only found one og:url.
So why is it complaining?
The two URLs that according to facebook are in my page are identical!
You have specified an OG url in two places
<!-- Facebook Opengraph -->
<meta property="og:url" content="http://www.eve.com.mt/2012/11/16/is-living-abroad-something-for-everyone/">
and
<meta property="http://ogp.me/ns#url" content="http://www.eve.com.mt/2012/11/16/is-living-abroad-something-for-everyone/">
A possible cause for this in WordPress is using having two plugins update meta data at the same time.
If you are using the Official Facebook WordPress plugin, your meta might be inserted from it.

Can You Have Your OpenGraph Object Link to a Different URL?

So you need a public URL with meta tags to represent an object in the OpenGraph, and one of the required meta tags is a URL property. When the action gets published, it links to this URL property.
Let's say I'm on http://mysite.com/A. It seems like I can't then do this:
<meta property="og:url" content="http://mysite.com/B"></meta>
Because Facebook will try to look at the root url for the meta tags. Is there any way to link to a different URL (mysite.com/B) from a given OpenGraph object URL (mysite.com/A)?
You should be able to link to another URL. But all an og:url means is "go over to that URL and use the tags from there instead". You can either
1) put all your tags on A and then redirect users to B with JavaScript or User-Agent detection;
2) put your content on A and do an og:url to B.
#Paul, I didn't fully understand or appreciate your comment until now - apologies and thanks.
What I learned from a little more tinkering is that on the initial post to FB with the object item url in the post, is that FB then crawls that page, gets the META tags and if you've got og:url defined it will crawl it again. It crawls it twice.
In my case, I am passing a querystring that does get parsed, but I was not setting it again in the og:url, so when it crawled my page the second time, it was not picking up the querystring variable I needed it to.
That was a dumb thing on my part. Thanks for the great answer.
Jim

Facebook URL Linter pulls data for wrong page

My team recently launched a Web app that makes heavy use of Facebook's Like Button. Most of them work fine, but several of the Like URLs aren't recognized correctly by Facebook or its URL Linter. These URLs are for a page on our app that redirects to a corresponding page in a Facebook app...
Example URL:
http://www.3mframeworks.com/pages/redirect?url=http%3A%2F%2Fapps.facebook.com%2Fcouplespeak%3Fv%3Dvideos%26id%3D17
Facebook's URL Linter returns data as if the "id" parameter isn't there:
https://developers.facebook.com/tools/lint?url=http%3A%2F%2Fwww.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fv%253Dvideos%2526id%253D17
Other Open Graph parsers return the correct data:
og:it: http://ogit.heroku.com/inspect?url=www.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fv%253Dvideos%2526id%253D34
OpenGraph.In: http://www.opengraph.in/?url=www.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fv%253Dvideos%2526id%253D34&format=html
I've spent hours searching for an explanation...
Facebook's documentation, under Editing Meta Tags, states:
"Note that og:title and og:type are only editable initially - after your page receives 50 likes the title becomes fixed, and after your page receives 10,000 likes the type becomes fixed." My Like counts are nowhere near these numbers.
"For the changes to be reflected on Facebook, you must force your page to be scraped. The page is scraped when an admin for the page clicks the Like button or when the URL is entered into the Facebook URL Linter. You can programmatically force your page to be scraped by cURL'ing the linter." I have tried all three of these methods without success.
Facebook Like button - fetches "wrong" image suggests that linting an URL doesn't reset the cache as Facebook claims.
Facebook Open Graph not clearing cache suggests this may be Facebook caching that will fix itself after an unknown period of time.
facebook like button liking wrong url suggests waiting 24-32 hours for Facebook's cache to be reset. It has been 64+ hours since my Open Graph tags were last set.
Why is Facebook returning the wrong page (affects Facebook Like and Share URL)? suggests that any URL provided to Facebook (e.g. via a Like Button) before being published should be changed. I tried changing the URL, renaming the id parameter, without success.
The most likely culprit seems to be Facebook caching, but it's already been suspiciously long and since this site is part of a currently live campaign that emphasizes Like activity, I'm hoping someone knows a trick to get this working ASAP. Thanks!
Some piece in Facebook's Graph API and URL Linter drops all but the first of multiple URL parameters.
Graph API
When the parameter string is "?v=videos&id=17", "id" is lost:
https://graph.facebook.com/http%3A%2F%2Fapps.facebook.com%2Fcouplespeak%3Fv%3Dvideos%26id%3D17
When the parameter string is "?id=17&v=videos", "v" is lost:
https://graph.facebook.com/http%3A%2F%2Fapps.facebook.com%2Fcouplespeak%3Fid%3D17%26v%3Dvideos
This doesn't happen if the Graph "id" parameter is declared explicitly: https://graph.facebook.com/?id=http%3A%2F%2Fapps.facebook.com%2Fcouplespeak%3Fv%3Dvideos%26id%3D17
Unfortunately that third point doesn't help my situation: I'm not accessing the Graph directly, so I can't just insert "?id=".
URL Linter
For my app, all parameters are needed to render the correct Open Graph meta tags, and the results support my discovery:
When the nested, encoded parameter string is "?v=videos&id=17", Open Graph tags are rendered for "3M Couple Speak Video Contest". This is the expected behavior when the "id" param is absent:
https://developers.facebook.com/tools/lint?url=http%3A%2F%2Fwww.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fv%253Dvideos%2526id%253D17
When the nested, encoded parameter string is "?id=17&v=videos", Open Graph tags are rendered for "3M Couple Speak Translation Contest". This is the expected behavior when "v=videos" is absent:
https://developers.facebook.com/tools/lint?url=http%3A%2F%2Fwww.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fid%253D17%2526v%253Dvideos
This doesn't happen with non-nested, non-encoded parameter strings:
https://developers.facebook.com/tools/lint?url=http%3A%2F%2Fapps.facebook.com%2Fcouplespeak%3Fv%3Dvideos%26id%3D17
For other Open Graph parsers, switching the order of nested, encoded parameters yields the same data, which is correct:
http://ogit.heroku.com/inspect?url=www.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fv%253Dvideos%2526id%253D17
http://ogit.heroku.com/inspect?url=www.3mframeworks.com%2Fpages%2Fredirect%3Furl%3Dhttp%253A%252F%252Fapps.facebook.com%252Fcouplespeak%253Fid%253D17%2526v%253Dvideos
Unfortunately, again, that third point doesn't help my situation: we need to nest and encode the URL.
This explains the bad data I'm seeing, and why it only happens to the URLs with multiple parameters. I submitted a bug report to Facebook.
The iframe source on that Facebook page is at this url it seems:
couplespeak-3m-production.heroku.com/videos
and that page contains the tags that show up in the Facebook Linter.
<meta content='3M Couple Speak Video Contest' property='og:site_name' />
<meta content="3M Couple Speak Video Contest" property="og:title" />
<meta content="website" property="og:type" />
<meta content="http://apps.facebook.com/couplespeak?v=videos" property="og:url" />
<meta content="http://www.3mframeworks.com/images/video_background.jpg" property="og:image" />
<meta content="100001154487117" property="fb:admins" />