The Invisible Half of a Blog Post

4 August 2026 · technology writing

When I publish a post here, the words are roughly half the file. The other half is metadata: forty-odd lines in the page's head, plus entries in two site-wide XML files. Skipping it all would change nothing about the reading experience, but it's necessary and is checked by a machine. This post describes it. Part of the series on how this site is built.

Quick jargon guide

  • Metadata: data about the page rather than in it: its title, summary, author, date, and preview image, written in machine-readable form.
  • Open Graph: the tag family (invented by Facebook, used by everyone) that controls the card shown when your link is shared in a chat or feed.
  • Canonical URL: a tag declaring "this address is the one true home of this page", so search engines don't treat variants as duplicates.
  • JSON-LD / structured data: a machine-readable summary of the page (this is an article, by this person, on this date) in a format search engines parse directly.
  • RSS feed: a site-wide XML file listing recent posts, so feed readers can check for new writing without visiting.
  • Sitemap: a plain list of every page you'd like search engines to know about.

The card in the chat window

Open Graph: five tags giving the post's title, description, preview image, address, and type. When someone pastes your link into a group chat or a social feed, the platform reads these tags to build the preview card. Without them, your link renders as bare blue text or, worse, a card assembled from whatever the scraper found first. With them, every share has a title, summary sentence, and one of my photographs at full card width. Twitter's near-identical tag family sits alongside for the platforms that read that instead.

<meta property="og:title" content="The Invisible Half of a Blog Post">
<meta property="og:description" content="Every post on this blog carries around forty lines
      of metadata nobody reads: social preview cards, structured data, feeds, citation tags.">
<meta property="og:image" content="https://github.com/DrKenReid/DrKenReid.github.io/releases/download/photos-v1/78.png">
<meta property="og:url" content="https://www.kenreid.co.uk/blog/invisible-half-of-a-blog-post.html">
<meta property="og:type" content="article">

The description gets written by a human (me), because it's the sentence that decides whether a stranger clicks. And the image tag points at a full-resolution photo, not a thumbnail, because preview scrapers resize down gracefully and up horribly.

The librarian's copy

Below the social tags sits a block of JSON-LD: the same facts (headline, author, date, image) restated in schema.org's vocabulary, which is the format Google actually parses for rich results. Where the Open Graph tags talk to chat apps, this block talks to crawlers, and it's how I explain that this page is an article by me.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "The Invisible Half of a Blog Post",
  "author": { "@type": "Person", "name": "Ken Reid", "url": "https://www.kenreid.co.uk" },
  "datePublished": "2026-08-04",
  "image": "https://github.com/DrKenReid/DrKenReid.github.io/releases/download/photos-v1/78.png"
}
</script>

Each post carries citation tags (the format Google Scholar reads) and Dublin Core tags (the library world's metadata standard). I spent years in academia, the tags cost six lines, and if someone ever does want to cite the scrobbles post in their media-studies dissertation, their reference manager will fill every field correctly. It's courteous and costs me nothing but a couple of seconds, and might give another citation or two to my Google Scholar account!

<meta name="citation_title" content="The Invisible Half of a Blog Post">
<meta name="citation_author" content="Reid, Kenneth N.">
<meta name="citation_publication_date" content="2026/08/04">
<meta name="DC.title" content="The Invisible Half of a Blog Post">
<meta name="DC.creator" content="Kenneth N. Reid">
<meta name="DC.date" content="2026-08-04">
A four-pane skylight in a dark wooden attic roof, bright sky showing through
© Ken Reid. All rights reserved. The part of the structure you only notice when the light comes through it.

The site-wide ledgers

Two XML files round out every publish. The sitemap is a list of every page, so crawlers miss nothing. The RSS feed is how readers with feed readers (a small, excellent demographic) get new posts delivered without visiting, and it's essential infrastructure here. RSS predates the social platforms and will outlive several of them.

<!-- feed.xml -->
<item>
  <title>The Invisible Half of a Blog Post</title>
  <link>https://www.kenreid.co.uk/blog/invisible-half-of-a-blog-post.html</link>
  <pubDate>Tue, 04 Aug 2026 00:00:00 +0000</pubDate>
</item>

<!-- sitemap.xml -->
<url><loc>https://www.kenreid.co.uk/blog/invisible-half-of-a-blog-post.html</loc>
     <changefreq>yearly</changefreq><priority>0.8</priority></url>

Each post also declares a canonical URL: the www and non-www versions of your site, plus any URL with tracking junk appended, all count as different pages to a search engine, splitting your modest search presence into fragments. One tag per page declares the official address and the fragments reunite.

<link rel="canonical" href="https://www.kenreid.co.uk/blog/invisible-half-of-a-blog-post.html">

The real problem is discipline

Nothing above is hard. The hard part is that it's forty lines of near-identical boilerplate on every post, and near-identical is the operative curse: copy the head from the last post, forget to change the og:image, and next week your post about cats is shared around wearing a photograph of a dog.

So: automate the checking, not necessarily the writing. My audit script validates every page's metadata (descriptions present and sensibly sized, canonical matching the filename, preview images existing, JSON-LD parsing, feed and sitemap complete) on every push. The forty lines stay correct because a robot reads them. Without that, my genuine recommendation would be to keep less metadata: only what you can maintain, because wrong metadata is worse than none.

Common questions

What's the minimum set worth having?

Title, description, canonical, and the Open Graph tags with a real image. That covers search snippets and share cards, which is where the visible benefit lives. Add RSS if you post regularly; it's one generated file and your most loyal readers will use it. Everything beyond that is diminishing returns done for craft.

Does any of this improve search ranking?

Mostly no, and be suspicious of anyone selling otherwise. Metadata doesn't make a page rank higher; it makes the page present correctly wherever it appears: the right snippet, the right card, the right attribution.

How do I check what my links look like when shared?

Paste the URL into a private chat with yourself and see what unfurls.

Why not generate all this with a static site generator?

A generator absolutely would, from a few front-matter fields, and it's a fine reason to use one. This site is hand-built by choice (a decision explained elsewhere), so the equivalent is a checked template: same output, different division of labour between me and the machines.


Back to all posts