hCard microformat

hCard is an open microformat for publishing contact information in structured form. Its premise is economical: you mark up data already on the page with class names, so the same text serves people and machines. Nothing new is written and nothing changes visually.

How it looks

An ordinary block of contact details — name, city, street, telephone, opening hours — becomes a card by wrapping it in a vcard root and labelling each fragment: category, fn org, locality, street-address, tel, workhours.

Why it still matters

Yandex reads hCard into Yandex Business, which feeds Maps and the address snippet in search results. So contact markup on a site is not decorative: it is a submission channel to the mapping product, and for a business with branches it keeps that data current automatically whenever the site changes.

Its one structural weakness

Because meaning rides on class attributes — which are also styling hooks — a CSS refactor can delete the markup without changing anything visible. This is the argument for Schema.org on new work, where the attributes have no other purpose. Existing hCard should be left in place and re-validated after template changes.

Where it fits alongside Schema.org

Yandex supports both and prefers neither, recommending Schema.org as the more modern standard. For contact data specifically, hCard remains fully processed and is the older, widely deployed option — which is why it survives on so many sites and why knowing its rules is still worth an afternoon.

The practical minimum

A card needs an organisation name, an address, and a telephone number to be accepted into Yandex Business. Everything beyond that — category, email, coordinates, URL, opening hours — improves what users see about the business, and each addition is one class attribute on text that is already published.