Card looks right in validator, then doesn't work


#1

Hi there. I added Twitter Card meta tags to one of my pages, and used the validator, found here, to test it:

https://cards-dev.twitter.com/validator

It worked. The meta tags were in the BODY tag (long story, but I had to work around a templating system issue), but the validator read them all (it listed the number it found) and the preview was correct. Then, when I tweeted it out, it didn’t pick them up. It worked fine after I moved them to the header. No issue with the meta tags having to be where, semantically, they should be, but the validator, I assume, shouldn’t say they’re fine elsewhere if they’re not.


#2

Can you please share a link to test from my end?


#3

Did you have any other meta tags in the header previously? The count listed by the validator is for all of the meta tags, whether or not they relate to the card.


#4

Thanks for the replies.

@RamiZebian. Sure. Here’s a copied test page with the meta tags in the body. It looks/looked correct in the Card Validator linked above: http://www.spypartyfans.com/test.html

@andypiper Yes, I had other meta tags. I understand the count is for all of them. I mention it only to illustrate that it was, in fact, detecting the tags, even though they weren’t in the head tag.


#5

I tried testing the preview on other social media networks as well and the image does not show.

Your page has meta tags in the body instead of the head. This may be because your HTML was malformed and they fell lower in the parse tree.

Also, some scrapers show the below HTML tags. Where does the <img> tag come from right after the <body>?

<body>
<img><meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@spypartyfans">
<meta name="twitter:creator" content="@spypartyfans">
<meta property="twitter:image" content="http://www.spypartyfans.com/images/scl_moderne.png?v=3">
<meta property="twitter:image:width" content="1280">
<meta property="twitter:image:height" content="640">
<meta property="og:url" content="http://www.spypartyfans.com/signup-test.html">
<meta property="og:title" content="SCL Season 5 Signups">
<meta property="og:description" content="Signup for the fifth season of the SpyParty Competitive League">
<meta property="og:image" content="http://www.spypartyfans.com/images/scl_moderne.png?v=4">
<meta property="og:image:width" content="1280">
<meta property="og:image:height" content="640">

#6

Thanks for the response. I understand meta tags in the body are not semantically valid (as I mentioned in the OP, I put them there initially to get around an issue with some templating software). The issue is that the Card Validator says it’s fine, anyway, even though it obviously isn’t when the tweet goes out. No issue with Twitter Cards requiring proper meta tag placement, but if that’s the case, the Validator obviously needs to throw an error.

There is no img tag inside the body of the test page I uploaded, and I don’t see it when I view the source. Not sure what scraper you’re using, but it seems to be inserting that.


#7

I see your point. I have no idea regarding the Card Validator issue.

On the other hand, check this out. That’s where the <img> tag shows. Not sure if it is related to the kind of error you get but worth having a look just in case:

https://developers.facebook.com/tools/debug/echo/?q=http%3A%2F%2Fwww.spypartyfans.com%2Ftest.html


#8

Very strange, no idea why that tool is adding an img tag.

Anyway, would very much appreciate some kind of response from Twitter as to why the card validator approves things that don’t work. Totally fine with requiring semantic meta tags, but the validator definitely shouldn’t be signing off on it if it’s not going to work. Seems like a huge issue. A validator that validates incorrectly is kinda worse than no validator at all.


#9

It’s difficult to say what has happened in this case, as it sounds like you’ve now got the meta tags in the expected place. However, your test URL does seem to be showing a card - I’ll raise this as an issue with the relevant team, as that does not seem correct to me.


#10

Thanks, and yeah, the test URL is definitely the relevant one for these purposes. Appreciate you forwarding it along.