Looking for fresh ideas on why Twitter’s card crawlers suck at pulling images for my links. When I first set the cards up (late last year I think) they were consistently pulling the image to present correctly. I left Twitter behind and threw more energy into the blog. I secured the custom domain moondeer.blog to replace the use of moondeer.micro.blog. After six months of nobody reading my posts I get back on Twitter.
Now the Twitter cards are a crapshoot, mostly pulling this sh$te
Apparently throwing money into a promoted ad forces their crawlers to get their sh$t together. I am testing whether promoting makes a difference and at the same time I got an email saying my account was approved, the cards started fetching images again. There was also something in the ads interface about a change coming to cards. It might shake itself out.
And adding that I’ve noticed I only get images fetched for posts crawlable from links I tried to promote. Visits showed up in Analytics as Twitter Ad Tool. Super annoying that this must be an issue on their end.
So this is driving me nuts. @manton … or anyone … have a current theme configuration for which Twitter is happily fetching card images? It feels like the problem must be Twitter’s card crawler but I’ve no idea how I’m tripping it up. Every other platform accurately parses the meta tags for a proper render.
I don’t understand why this isn’t working either. Your HTML looks fine to me on first glance, but maybe Twitter did change something. They have this card validator which is also not showing the image: https://cards-dev.twitter.com/validator
Yeah, drives me nuts … scrapers seem to find the image without problem but the crawlers (Twitter and possibly Mastodon, not sure as I only recently realized Metatext had cards) don’t find it.
The one week I ran Twitter promotions … one included a blog post link … all the sudden it seemed a lot of my site was crawled again. Stop promotions … caches empty … and back to blank images.
IOS messages and Telegram also happily display the images.
since I just used cloudflare to control the SSL on moondeer.art … I thought I would do the same with moondeer.blog after seeing that Twitter’s card crawlers require TLS 1.1. Their docs pointed me to this SSL test
There should be results cached for moondeer.blog and moondeer.micro.blog.
I captured a PDF of the results for moondeer.blog before changing nameservers to cloudflare … but it seemed to check out okay as far as TLS is concerned.
What I did notice:
Both domains report inconsistent configuration. For moondeer.micro.blog, a test runs for the IP4 address and attempts for an IP6 address (I’m assuming). For moondeer.blog, the test runs for three IP4 addresses and attempts for their three IP6 counterparts (I’m assuming). None of what I assume are IP6 addresses establish a connection … which I would assume is the reason both servers get the inconsistent configuration warning.
Also of note, there are two expired certificates in the resolution path for moondeer.micro.blog. The third certificate resolves … but since we have no idea what is causing the Twitter card crawler issue … it seems suspicious that the second certificate just expired in late March.
My knowledge in this area is pretty limited … but there is now some form of documented resolution weirdness … and the bit about the card crawler at the end of this documentation:
The logged in problem is probably because of some NoPreview setting, which does this to standard images, but seems to fully block all images on og:cards :
I’ll have peek later, out of nowhere yesterday a link had its image properly fetched. No way to isolate what caused the successful fetch so jury is still out. I’ll add logged in/logged out scenarios next time I piddle.
