skip to main content

Bloggers, Dump Your Twitter Card Tags

published icon  |  category icon webdesign

It’s astonishing how much influence a single company can have, even on the invisible part of the webdesign of your blog: the metadata. I still encounter countless sites—including my own, before cleaning up—that feel obliged to inject <meta name="twitter:title"> tags in their <head/> segment of the HTML. Because otherwise the SEO isn’t optimized, oh no! But since Twitter has gone to shit, I figure we don’t need any tag or embed anymore that contains the term twitter.

To be honest, I wonder why we needed something like that in the first place. There are already countless of metadata systems out there that happily clog up bandwidth. Let’s list a few:

1. Old school HTML tags

Remember these? The <title/> tag, together with the <meta/> tags named keywords, description and the optional viewport settings should be enough for any bot to get a first grasp on what the site is about. It baffles me that all proprietary newer systems push you to duplicate that information in their own version of a title or description tag, while that has been around for decades.

2. The Open Graph protocol

Arguably the most (in)famous, another one from a big company: the Open Graph protocol. Why they think it’s important to us website builders:

The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook.

For this article, it looks like this:

<meta property="og:site_name" content="Brain Baking">
<meta property="og:title" content="Bloggers, Dump Your Twitter Card Tags">
<meta property="og:description" content="It&rsquo;s astonishing how much influence one company can have, even on the invisible part of the …">
<meta property="og:url" content="https://brainbaking.com/post/2022/11/bloggers-dump-your-twitter-card-tags/" />
<meta property="og:type" content="article" />
<meta property="og:image" content="https://brainbaking.com/img/bblogo.png" />

As said before, why does og:title and og:description exist if there’s a perfectly fine <title/> and description tag already in use? You can circumvent adding another description tag by adding that property to the previous meta tag. The attribute here is called “property” and not “name”, meaning we can mix and match.

Meta’s tags are not as bad as Twitter’s—it’s called og:title and not facebook:title. Furthermore, the OG “standard” has been adopted by other social media sites that want to display rich information for a link, such as LinkedIn, Mastodon, and Discord—even though nowadays they prefer yet another standard. Great!

Unfortunately, “adoption” also means “extension”. For instance, Pinterest supposedly creates its own og: tags and makes use of the semi-unofficial og:see_also tag that I used to support but easily adds 5+ lines of more junk and there’s no sign of it on the official OG website, so I don’t anymore.

3. LD+JSON

The JavaScript Object Notation for Linked Data should offer bots easier access to the gist of your article and help optimize search results. It’s primarily used by search engines like Google and Bing to facilitate indexing since it’s structured data. But it’s still metadata that summarizes the content in very much the same way as the above Open Graph, which means that if you support both, you’re serving bytes that contain a lot of duplicate data, which drives me crazy. Surely engineers at Google and Microsoft are smart enough to leverage existing other protocols?

For this article, it looks like this:

{
    "@context" : "https://schema.org",
    "@type" : "BlogPosting",
    "mainEntityOfPage": {
         "@type": "WebPage",
         "@id": "https://brainbaking.com/"
    },
    "articleSection" : "post",
    "name" : "Bloggers, Dump Your Twitter Card Tags",
    "description" : "It\u0026rsquo;s astonishing how much influence one company can have, even on the invisible part of the …",
    "inLanguage" : "en-US",
    "isFamilyFriendly": "true",
  	"image": "https://brainbaking.com/img/bblogo.png",
    "author" : {
    	"@type": "Person",
    	"name": "Wouter Groeneveld"
	  },
    "creator" : {
        "@type": "Person",
        "name": "Wouter Groeneveld"
    },    
    "publisher": {
    	"@type": "Organization",
    	"name": "Brain Baking",
      "url": "https://brainbaking.com/",
    	"logo": {
    		"@type": "ImageObject",
    		"url": "https://brainbaking.com/img/bblogo.png",
        "width":"32",
        "height":"32"   
    	}
	  },
    "accountablePerson" : "Wouter Groeneveld",
    "copyrightHolder" : "Brain Baking",
    "copyrightYear" : "2022",
    "dateCreated": "2022-11-27T09:01:00+01:00",
    "datePublished": "2022-11-27T09:01:00+01:00",
    "dateModified": "2022-11-27T09:01:00+01:00",
    "url" : "https://brainbaking.com/post/2022/11/bloggers-dump-your-twitter-card-tags/",
    "wordCount" : "89",
    "keywords" : [ "blogging","Bloggers, Dump Your Twitter Card Tags", "post" ]
}

That is a lot of data, and I’m not even using half of the functionality—if you host a Wordpress site and optimize it with a plugin like Yoast, you’ll be (most likely unconsciously) using twice as many properties. Great! Sigh. Since the schema supports nesting, you can add in comment sections, content within content, … Don’t forget to validate your JSON. Don’t forget that Google has its own validator that returns other warnings because it’s Google.

We’re not done yet.

4. Dublin Core metadata

Dublin what? The Dublin Core Specification, used by archivists and X/HTML enthusiasts, describes “DC-HTML” which can be added as metadata to hold… exactly the same information as the ones above.

For this article, it would look like this:

<head prefix="dc: http://purl.org/dc/elements/1.1">
<meta property="dc:creator" itemprop="author" name="author" content="Wouter Groeneveld" />
<meta property="dc:date" itemprop="datePublished" name="date" content="2022-11-27T09:01:00+01:00" />
<meta property="dc:description" itemprop="description" name="description" content="It\u0026rsquo;s astonishing how much influence one company can have, even on the invisible part of the …" />
<meta property="dc:format" itemprop="encodingFormat" content="application/xhtml+xml" />
<meta property="dc:identifier" itemprop="sameAs url" content="https://brainbaking.com/post/2022/11/bloggers-dump-your-twitter-card-tags/" />
<meta property="dc:language" itemprop="inLanguage" content="en-US" />
<meta property="dc:publisher" itemprop="publisher" content="Brain Baking" />
<meta property="dc:subject" itemprop="keywords" name="keywords" content="blogging, post" />
<meta property="dc:title" itemprop="name" content="Bloggers, Dump Your Twitter Card Tags" />
<meta property="dc:type" content="text" />
</head>

Why would you use DC? The ultimate goal of the initiative is to create a digital “library card catalog” for the web, offering the above specialized properties to also help with indexing. In essence, the way I understand it, it’s an alternative for JSON-LD, that is heavily underused compared to JSON-LD.

DC goes way beyond cataloging and indexing web data: it is also widely used to describe a set of physical and non-web enabled digital resources.

Are we there yet? No.

5. Microformats

Microformats adopts another strategy: re-use existing data that is already there by labeling them:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns.

Instead of adding junk in the <head/> tag, label specifics in your article body accordingly. An example can be found at https://microformats.io/ or just by looking at the source of this page. Author information is wrapped in a h-card class. Article content is identified by e-content. There’s a slew of other tags available, but the gist is: don’t add more junk! Except that you have to add junk classes to your existing tags. Hmm…

I’ve been critical about some of these tags before. For instance, h-entry, the “root”, is useless: in 99% of the cases, there’s supposed to be only one, so just machine-parse at the actual root: the <html/> tag. Then there’s the ghost classes you easily mistake for genuine CSS classes. The biggest annoyance is having to redesign the structure of your page to be able to fit a h-card within an entry, making Microformats perhaps even a worse choice compared to slapping a few extra tags in your header and calling it a day. Do you want clutter up front or clutter in-between the rest?


Are we there yet? No—hi, oEmbed, sup?—but let’s pull over here because my head is spinning.

Clear up a little bit of space. Reduce your pages by a few bytes. Get rid of your twitter: metadata tags. It makes no sense to include the name of a (sinking) company instead of relying on a W3C-formalized standard to describe your metadata.

tags icon html metadata blogging

It seems like a lot of people (W, J and H) are cleaning up their . I always tried to be minimalist in my HTML (and I did meditate back when I build the current version of my site), so my head was actually already rather empty. I did however rem...

 | by 

It’s crazy to think how much bandwidth is being used by metadata tags. Every company wants to invent it’s own new system. Wouter Groeneveld gives a brief overview and recommends getting rid of them (for the most part). I agree with him completely...

 | by 

I'm Wouter Groeneveld, a Brain Baker, and I love the smell of freshly baked thoughts (and bread) in the morning. I sometimes convince others to bake their brain (and bread) too.

If you found this article amusing and/or helpful, you can support me via PayPal or Ko-Fi. I also like to hear your feedback via Mastodon or e-mail. Thanks!