SSM - Single Standard for Metadata

SSM - Single Standard for Metadata
Standards

28

9 min.

Definitions

The SSM standard defines requirements for the semantics, accessibility, and logic of metadata.

Structure and Semantics

Page Title and Description

  • Every indexable page has a unique, accurate <title>. It briefly describes the main content and is not replaced by the site name or generic template text.
  • Every indexable page has a unique, useful description. It must reflect the visible content rather than consist of a list of keywords.
  • There is no universal character limit for <title> or the description. A search engine may truncate the title or generate the result title and snippet from other parts of the page.
  • The page description may be used to create a search snippet, but a search engine may choose another text excerpt. The title and description do not guarantee clicks or search positions.

Canonical URL

  • For a set of duplicate or very similar URLs, specify the preferred canonical address with rel="canonical" or an appropriate HTTP response mechanism.
  • The canonical address must lead to an accessible page with equivalent main content. A stable absolute HTTPS URL and a self-referencing canonical on the preferred version are generally used.
  • A canonical is a signal to a search engine, not an unconditional command. It helps identify a preferred URL and consolidate signals for similar pages, but it is not a way to hide a page or protection from an automatic “duplicate content penalty.”
  • Different language versions with translated main content should not be canonicalized to a single URL. Each version has its own canonical URL and is connected through hreflang.

Indexing and Crawling

  • Indexing and crawling are separate processes. robots.txt controls access to URLs and resources for compatible crawlers, but it is not, by itself, a reliable way to exclude a URL from search results.
  • To exclude an accessible page from an index, use a supported noindex directive in page metadata or the X-Robots-Tag HTTP header. A crawler must be able to fetch the page to process the directive.
  • A URL blocked in robots.txt may remain known to a search engine through external links even when the crawler cannot access its content. Therefore, robots.txt is not a confidentiality mechanism.
  • index and follow are generally the default behavior; they do not need to be specified without a reason. Directive values and support must be checked for the target search engines.
  • Restricted or confidential content must be protected with authentication and access controls, not only metadata or crawl rules.
  • Accessible pages must return the correct HTTP status. Set up a redirect for a moved resource and the appropriate not-found status for a removed one. An XML Sitemap helps crawlers discover preferred URLs, but does not guarantee crawling or indexing.

Example directive for excluding a page from an index:

<meta name="robots" content="noindex">

The crawler can read this directive only when it crawls the page. If the URL is also blocked in robots.txt, the crawler may not receive the noindex directive.

Metadata Delivery

  • Critical metadata must be available to the crawlers and platforms it targets. If a consumer's JavaScript processing is unknown or limited, metadata must be included in the initial HTML response or HTTP headers.
  • For client-side generation, check the final rendered document and the actual HTTP response. Metadata changes during hydration must not leave conflicting values or multiple canonical URLs.

Localization and Language Versions

  • When translations are available at separate URLs, each language version must have its own permanent address and canonical URL pointing to the version in the same language with the corresponding content.
  • Connect equivalent pages with rel="alternate" and valid hreflang values. Each version must list itself and the other available versions; the set of links must be reciprocal, and target pages must be crawlable and indexable.
  • Use valid language codes in hreflang, adding a region when necessary. x-default may be used for a default page intended for users who do not match a specific language version.
  • Specify the document's primary language with the lang attribute. It helps assistive technologies and user agents identify the content language, but does not replace hreflang.
  • og:locale sets the Open Graph locale in language_TERRITORY format, such as en_US. Repeated og:locale:alternate properties list the other locales in which the page is available.
  • og:locale:alternate does not connect translated URLs and does not replace hreflang. The alternate locale list must match the translations that are actually available.

Example language URL mapping:

<html lang="en">
<head>
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">
</head>
</html>

The same complete set of reciprocal links appears on every language version, with the corresponding lang value.

Open Graph

  • For an Open Graph preview, specify og:title, og:type, og:image, and og:url — the protocol's core properties.
  • og:description briefly describes the specific page. og:image:alt is recommended for an image; it describes the image content rather than providing a post caption.
  • The image URL and og:url must be absolute addresses that are publicly accessible. HTTPS is preferred for images; the resource must load without authentication and must not be blocked from platform crawlers.
  • Open Graph values must describe the specific page being shared. og:url must agree with the page's preferred permanent address.
  • og:locale and og:locale:alternate provide locale information for the object, but do not guarantee that a social platform will display a localized preview.

X Cards

  • X card metadata can use twitter:* properties, including twitter:card="summary_large_image", when that format is supported for the target post type.
  • summary_large_image selects a card layout with a large image; it does not guarantee maximum reach, CTR, or priority in a feed.
  • X metadata should not be treated as universal across social networks. Support, precedence, and preview caching vary by platform and may change.
  • A card's title, description, and image must match the page content. Some platforms may use Open Graph values when separate settings are absent, but this behavior must be checked on the target platform.

Site and Web App Icons

Site Icons

  • Specify one or more site icon files with the rel="icon" link relation. Supported formats and sizes depend on the browser and display context.
  • SVG is suitable for a scalable icon, but should not be treated as the only universally supported format. Add an ICO or raster version when needed for compatibility with target browsers and environments.
  • A favicon must be square, publicly accessible, and served from a stable URL. Sizes such as 16×16, 32×32, and 48×48 are options, not a mandatory exhaustive set.
  • The icon used in a browser tab or search result may be defined differently from the icons used by an installable web app.

Web App Manifest and Mobile Platforms

  • Link to site.webmanifest when the site needs web app configuration. A manifest can define the app name, start URL, display mode, theme, and icon set.
  • Manifest icons must include accurate format, size, and purpose information when needed for file selection. A 192×192 and 512×512 set is commonly used for compatibility with some installation environments, but is not a universal requirement for every site or device.
  • A manifest alone does not turn a site into an installed app or guarantee that it can be installed. Support and installation criteria depend on the browser, operating system, and site capabilities.
  • theme_color in a manifest or the corresponding metadata element may affect browser or app interface colors. Support and visual effects vary across platforms.
  • apple-touch-icon and apple-mobile-web-app-capable relate to adding a site to the Home Screen and launching it in a separate window on Apple devices. These are platform-specific settings, intended only when that scenario is supported; they are not required for an ordinary website.
  • A manifest and separate Apple icons may compete for icon selection. Verify which icon is actually used in the supported operating system and browser versions.

Structured Data

  • Add structured data only when it accurately describes the page's visible content and is appropriate for its type.
  • JSON-LD is one structured data format and is the format preferred in Google's documentation. Select a schema and properties according to current Schema.org documentation and the requirements of the specific consumer.
  • Markup may make a page eligible for certain rich results, but does not guarantee that they will be displayed and does not replace useful content.
  • Ratings, prices, product availability, and other changing information must be accurate, current, and visible to users. Syntactically valid but misleading markup does not meet the purpose of structured data.

Example JSON-LD for content that matches the Article type:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article title",
  "image": "https://example.com/en/images/article.webp",
  "datePublished": "2026-09-26",
  "dateModified": "2026-09-26"
}
</script>

Populate the example fields with the page's actual data. Use the appropriate type and properties for other content; optional fields must not be filled with fictitious values.

Testing

  • Check that each indexable page has a unique <title> and description that match its actual content.
  • Check the HTTP status, crawler access, and conflicts between robots.txt, noindex, redirects, and canonical URLs.
  • Check that the canonical URL points to the intended language version and agrees with internal links, the Sitemap, and og:url.
  • Check that the Sitemap is accessible and its URLs are correct. Listing a URL in a Sitemap does not confirm indexing.
  • For multilingual pages, check lang, all hreflang links, reciprocal mappings, and the accessibility of every version.
  • Check previews on target social platforms, including absolute URLs, image loading, title, description, locale, and cache behavior.
  • Check favicon, manifest icon, and web app display behavior in the declared browsers and operating systems.
  • Validate structured data with the Schema.org validator and rich result testing tools when they support the selected type. Validity does not guarantee a rich result.

SSM Checklist

CategoryCore elementsPurpose
Page metadata<title>, descriptionAccurate representation of a page in search
Indexingrobots, noindex, robots.txt, HTTP statusControl crawling and page eligibility for indexing
CanonicalizationCanonical URL, redirects, SitemapAlign preferred addresses and help URL discovery
Languageslang, hreflang, og:localeConnect language versions and specify locale
Social previewsOpen Graph, X metadataRepresent shared links on supported platforms
Icons and web appsFavicon, Web App Manifest, platform iconsIdentify the site and configure supported installation scenarios
Structured dataSchema.org, JSON-LDDescribe content structure and enable eligibility for supported rich results

Complete Metadata Example

This example shows the final document fragment. Metadata may be generated by a CMS, template, server rendering, static site generator, or another tool; the requirements apply to the resulting document and response, not to a platform-specific API.

<html lang="en">
<head>
  <title>Page title</title>
  <meta name="description" content="A concise description of the page content.">
  <link rel="canonical" href="https://example.com/en/article">
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">

  <meta property="og:title" content="Page title">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/en/article">
  <meta property="og:image" content="https://example.com/en/images/article-share.webp">
  <meta property="og:image:alt" content="Illustration for the article">
  <meta property="og:locale" content="en_US">
  <meta property="og:locale:alternate" content="ru_RU">
  <meta property="og:locale:alternate" content="de_DE">
  <meta property="og:locale:alternate" content="ja_JP">

  <meta name="twitter:card" content="summary_large_image">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="icon" href="/favicon.ico">
  <link rel="manifest" href="/site.webmanifest">
  <meta name="theme-color" content="#ffffff">
</head>
</html>

Similar categories:

Similar articles

  • Anatomy of a React component

    My vision for how every React component should look

    421

    8 min.

  • SST - Single Standard for Tabs

    The SST standard defines requirements for the semantics, accessibility, and logic of tabs

    62

    7 min.

  • SSF-U - Single Standard for Fullscreen

    The SSF-U standard defines requirements for the semantics, accessibility, and logic of fullscreen

    248

    2 min.

  • SSA - Single Standard for Accordion

    The SSA standard defines requirements for the semantics, accessibility, and logic of accordion

    258

    2 min.

  • Bad Practices for Websites

    An Analysis of Critical Web Design Mistakes. Why Sliders, Autoplay, and Slow-Loading Pages Reduce Conversion Rates and Rankings on Google

    232

    2 min.

  • SSP - Single Standard for Pagination

    The SSP standard defines requirements for the semantics, accessibility, and logic of pagination

    240

    1 min.

  • All articles

Contact me