Our app renders Like buttons that point back to an actual Facebook page. However, instead of pointing the Like button's href directly to the FB url, we proxy it through our servers through an opengraph endpoint. This is helpful because it allows us to have more detailed analytics on when these endpoints are used (amongst other things.) When these endpoints are hit with a user agent like 'facebookexternalhit', they render something like the following:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta property="fb:app_id" content="158708354177049" />
<meta property="og:site_name" content="BandPage" />
<meta property="og:url" content="http://www.facebook.com/stormystrongmusic" />
<meta property="og:type" content="band" />
<meta property="og:title" content="Stormy Strong" />
<meta property="og:description" content="..." />
<meta property="og:image" content="https://graph.facebook.com/20501829906/picture" />
<title>Stormy Strong</title>
<link rel="canonical" href="http://www.facebook.com/stormystrongmusic"/>
</head>
<body>
</body>
</html>
Note that both og:url and the link rel="canonical" point to the actual Facebook Page. In practice, this looks like it behaves fine when we try running the link through Facebook's debugger: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.bandpage-s.com%2Fogp%2F11601543111380992
However, there is a problem where, after an interval, the Like buttons appear to not resolve back to the page anymore. This results in the Like count being off, the button not being 'Liked' if you already like the page, etc. Manually triggering a re-scrape by going to the OG debugger url above solves the problem, for a time.
Obviously manually re-triggering these scrapes is not a tenable solution. Are there multiple scraper behaviors happening here? It seems like the scraper that is triggered w/ the debugger is different than the one that periodically re-scrapes automatically.
Why does this happen? Is there anything we can do to get around this, except for getting rid of our ogp endpoint 'middle-man' here? This seems like a perfect utilization of og:url.
