Facebook image problem

Problem: My site is producing the correct og:image URL (checked it in the source code for the page), but FB is, for some reason, picking up my logo at the og:image. (For every post)

The FB Sharing Debugger says “The ‘og:image’ property should be explicitly provided, even if a value can be inferred from other tags.” The problem is, the property IS explicitly provided, as shown in the code.

Thoughts?

Link the page, please?

All of them. If you hit the FB share button at the top, you will see what I’m saying.

Here’s one to try: Brian Clardy: ‘This changes the whole trajectory of the race.’

Note: One commenter elsewhere said that FB only parses the first 50kb of the head to get the og data. Don’t know if that’s true or not.

Update – Even when I go into an individual post and add the featured image to the “FB card” in the side panel, I still get the site logo in the FB post. All the other shares work fine.

One way to test that would be to change your theme so you’re not outputting a huge <style> block before the metadata tags.

We haven’t had any other reports of this problem so that first-50kb theory sounds plausible with your current site output.

Update: I tried down-revving the theme (to multiple versions ago), and the problem was still there.

I then tried changing to a different theme, and the problem was still there.

But here’s the thing: Sometimes, as I was testing, the problem went away. I thought “Aha! It’s this version that has the problem.” But the next time I tested, the problem was back.

I tried incognito windows and regular, across three different browsers.

At this point, I’m stumped.

Note that I do not have access to the back end, so I can’t test if this is a caching problem of some sort. (Which would make all the testing pretty much useless, since I can’t refresh the server’s cache of the site after changing themes.)

Thoughts welcome. I’m going to examine the two versions I tested first, to see if I can see something that might be causing this.

Bruce, Facebook caches results, so you aren’t going to see a change immediately, if you’re just trying to share the post normally.

The tool you’d want is this one:

(and I’m cracking up that THAT page doesn’t have all it’s og tags set!)

Be sure to tell it to rescrape (an option on the results page).

I think the “style tag too big” idea has some merit - and it’d be easy to test. Drop everything in that style tag into a css file, and replace with a line that loads that css.

(Alternately, move the partial that contains the css to below ghost_head, but note that this will mean your code injection header will get applied before most of the css loads, so the theme’s css will overwrite your code injection css if you don’t have enough specificity.)

Update: I think I have fixed it.

It would up being TWO different problems (which is what made it so hard to debug):

  • The CSS file was loaded before {{ghost_head}}, and was ginormous. (Even minimized.)
  • I had added code above the logo to load an ad, and for some reason that line of code made a difference as well.

So, I took out the line of code, and move {{ghost_head}} to about the third line of head.hbs. That seems to have taken care of the issue.

In the process, I did something to mess with the size of the site logo, which is now very small. But, that will have to wait to another day.

Thanks, all, for the help!

I’ll bet the code injection header has an adjustment for logo size. Try moving that to the footer.