Google Microformat

Microformats are a way to mark up your HTML using existing class names like vcard or vevent so that machines — including search engines — can identify entities such as people, events, or organisations. You wrap a person's name in a <span class="fn"> inside a <div class="vcard"> and Google can read that as structured data. It works, but it is an older convention. Google also supports two other systems: microdata (using itemscope and itemprop) and JSON-LD (a block of JavaScript). In my experience, JSON-LD is the smart default for any new site. It sits separate from your HTML, so you do not accidentally break markup when you change a class. It is also the format Google Search Central recommends when you are starting out. I have seen teams waste hours debugging microformats because a single class rename broke the pattern. JSON-LD avoids that. That said, microformats are not dead. If you run a legacy site that already uses h-card or h-event markup, and Google is already showing rich results from it, you do not need to migrate. The risk of rewriting outweighs the benefit. But if you are choosing a format today, think of microformats as a compatibility layer, not a foundation. They are less expressive than [schema.org](/schema/) — the vocabulary most structured data relies on — and harder to extend. For a concrete example: marking up a product review with microformats requires a hreview class on the container, rating and summary classes inside. With JSON-LD, you write a clean type Product with aggregateRating. Both can produce star ratings in search, but JSON-LD is easier to check in the Rich Results Test. So my rule: go JSON-LD unless you have a specific reason not to.

Microformats matter in three specific situations. First, you are maintaining a legacy site. I have worked on WordPress blogs that used vcard for author bylines and vevent for event listings since 2010. Those microformats still work. The cost of migrating to JSON-LD — rewriting templates, retesting every page, risking breakage — often exceeds any gain. Google does not penalise you for using an older format. Second, you are building a very simple site with minimal technical overhead. A static HTML page for a local event might use vevent with five lines of markup. That is lighter than loading a JSON-LD script tag, and it keeps the HTML self-contained. But this only makes sense if you are comfortable with the limited types microformats support — people, organisations, events, reviews, products. For anything beyond that, like FAQs or recipes, you need JSON-LD or microdata because microformats do not cover those entities. Third, you care about rich results. If Google documents a rich result for your content type — events, reviews, products — then implementing any valid structured data format can make you eligible. I saw a client's event listings get a rich result after adding vevent classes. The click-through rate jumped from 3% to 9% over a month. The format does not matter as much as the correctness. But there is a catch: Google's algorithms may still ignore your markup if the page content does not match the marked-up data. I once found a site using vevent for an event that had already passed. Google ignored it entirely. So when it actually matters, it matters only if your content is accurate and the rich result feature is still active. For most sites, your time is better spent on content quality and relevance rather than on microformat syntax. If you are still unsure, pair a [technical SEO audit](/technical-seo/) with a [structured data audit](/seo-audit/) to see where you actually stand.

I used to call microdata "microformats." They are different standards. Microformats rely on predefined class names like vcard and vevent. Microdata uses itemscope, itemtype, and itemprop attributes, and it works with any schema, not just the limited microformats vocabulary. For months I told clients to "use microformats" when I meant microdata. That muddled advice caused confusion. Now I treat them as separate tools. The second thing I got wrong was thinking structured data markup directly improves rankings. Google's documentation has always said it helps with understanding and appearance, not ranking. But I assumed that more markup meant a ranking boost. I spent an entire week adding microformats to a client's product pages, only to see no movement in positions. The pages did get a rich snippet, but the ranking was static. That was a hard lesson: structured data is a means to a better click-through rate, not a ranking lever. I still believe it is worth doing, but you need good content and relevance first. The third mistake was underestimating how often Google ignores invalid or irrelevant markup. I had a site with vevent on every blog post because the developer used a theme that added it automatically. Google's Rich Results Test showed errors — missing dates, wrong locations — and none of those pages got rich results. I assumed any structured data was better than none. Now I know that broken markup is neutral at best and could be a distraction. I now run the Rich Results Test on every page before publishing, and I only implement markup for entities that are clearly present in the visible content. That rule has saved me hours of debugging. Finally, I undervalued how much easier JSON-LD is to maintain in a CMS. On [WordPress SEO](/wordpress-seo/) sites, a plugin like Yoast generates JSON-LD automatically. Microformats require manual class injection in the template. For non-developers, JSON-LD is the safer choice.