Deep Debugging for Facebookers
Facebook Debugger: An essential tool
There is no question of the merits of using the worlds biggest social network for business purposes. If you still remain to be convinced, this post is perhaps not for you. Because this post looks at gaining the maximum control over how your material and the image in particular is displayed as a snippet on the Facebook platform.
Pages change but facebook remains the same
Within a few seconds on your favourite search engine will indicate the widespread frustrations users experience when sharing updated pages. You will also find a wide range of solutions to address issues raised by ‘Facebook’s Cache’.
Facebook’s Cache – In short
Without going into too much readily available detail here, in essence, for any web page, clicking the share button or entering the url directly in a status triggers Facebook to ‘scrape’ that page. A copy of the page is then cached so that the next time someone intends to share the same page information is retrieved from Facebook’s cache rather than the page itself.
With this understanding, it becomes clear that file names have a great importance. The mechanisms used to glean information about a web page are sensitive to change. Broadly speaking, whether the content of a page is new, i.e. if it has never been ‘introduced’ to Facebook before, and if not, whether its content has changed since the last scrape.
When is a change not a change?
There are any number of reasons a web page at a particular url might change its content and for the most part, Facebook’s caching system successfully detects these changes and updates its cache. Let us use a typical example where a typo is found in the title of a page ‘already introduced’ to Facebook. Someone has previously clicked a share button and triggered Facebook’s caching process. Correcting the typo and saving the relevant file alone will not change what is displayed the next time the page is shared. Until Facebook’s cache is refreshed, changes to the title, image or description will not be reflected in what appears in timelines. Its time to use the Facebook Debugger.
As I mentioned, instruction on usage of the debugger is covered elsewhere. In most cases updates such as that I describe above will be picked up by ‘forcibly’ refreshing Facebook’s cache. However, a persistent frustration with many who administer web pages that interact with Facebook relates to images intended to be included in what appears on a timeline. This is where file names come into play. The system Facebook uses to evaluate the contents of a page, frequently fails to detect a changed image if the image retains the same name it had before it changed.
Instead, the debugger might report:
og:image was not defined, could not be downloaded or was not big enough. Please define a chosen image using the og:image metatag, and use an image that’s at least 200x200px and is accessible from Facebook.
Again, solutions to these situations are not hard to find and will include renaming the updated image and amending the references to it in the web page itself or changing the way the updated file (with the same name as before it changed) is referenced in the web page, tricking Facebook into considering the image as ‘new’ and therefore should be cached. The former solution could mean duplication of the original with the renamed updated image in order to avoid broken links to the old image. Both solutions required some change in the code of the web page as well.
Making Facebook get the picture
When Facebook refuses to recognise your updated image and you can’t or don’t want to consider renaming files and updating code, there is an easy way to force Facebook’s cache into line.
The clue is in on the Debugger page and with the knowledge that a url is a:
. . . reference (address) to a resource on the Internet.”
this means the tool should successfully debug a url for an image resource and in so doing, refresh the cached version of that image. Here’s what happens.
After the first attempt at debugging an image resource, the signs are not good. A red danger sign and a error message. However, past experience with the debugger has taught us ‘it might take a few tries’ to get the results we seek.
On the third attempt, while red danger signs increased and error messages persisted, the resource (the image) was successfully retrieved, displayed and (presumably) cached. In my case it works! Changes to an image that retains its original name are reflected in what appears on timelines if the image itself is subjected to the Facebook Debugger. This proves very convenient, avoids duplication and saves having to fiddle around with code references to the image in the web page.
Have you been frustrated by Facebook’s caching system when it comes to updating images? What solutions work best?