The Metadata Nobody Sees (and Every Link Preview Reads)

You can spend a week on a homepage and still have every link to it render as a bare blue URL in a group chat. That is not a design problem. It is a metadata problem, and it takes about twenty minutes to fix.

Everything below lives in the <head> of a page. Nobody sees it while browsing, which is exactly why it gets skipped — and exactly why it matters, because it is the only version of your site most people will ever read.

Four tags, four different jobs

Four kinds of tags do four separate jobs. They are not interchangeable, and leaving one out does not break the page. It just quietly hands control of your presentation to whatever is scraping you.

• meta description — the sentence a search engine prints under your title in results. It is not a ranking factor. It decides whether anyone clicks. Around 155 characters before it is truncated, and Google rewrites it more often than it admits — but a hand-written one is still the version you want competing.
• og:title, og:description, og:image — what every messaging app, forum and social platform draws when somebody pastes your link. og:image wants a 1200×630 file at an absolute URL; relative paths fail silently on most scrapers. og:url should be the canonical link so shares count toward the right page. No image means a grey box. There is no version of that which looks intentional.
• twitter:card — whether that preview is a small square (summary) or a full-width image (summary_large_image). It falls back to og:image when twitter:image is missing, which is why most sites get away with defining one image and moving on.
• JSON-LD structured data — the machine-readable statement of who the page is about. This is how a search engine decides to attach your social profiles to your name instead of treating you as a stranger. It is one <script type="application/ld+json"> block. It changes nothing on screen and everything in a knowledge panel.

All four, in order, look like this:

<link rel="canonical" href="https://example.com/about">

<meta name="description" content="One sentence, written by hand, under 155 characters.">

<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/about">
<meta property="og:title" content="A title written for a human">
<meta property="og:description" content="The same sentence, or a shorter one.">
<meta property="og:image" content="https://example.com/card.jpg">   <!-- 1200x630 -->

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="A title written for a human">
<meta name="twitter:description" content="The same sentence, or a shorter one.">
<meta name="twitter:image" content="https://example.com/card.jpg">

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Your Name",
  "url": "https://example.com",
  "sameAs": [
    "https://www.instagram.com/you",
    "https://www.youtube.com/@you"
  ]
}
</script>

Check yours in thirty seconds

View the source of any page and search the head for og:. If nothing comes back, you currently have zero say in how your own links look when other people share them.

From a terminal the same check answers in one line:

curl -s https://example.com | grep -E 'og:|twitter:|canonical|name="description"'

Nothing printed means nothing declared. What you want to see is a full set — title, description, image, canonical URL — and then the image URL loaded on its own. If that URL shows a broken-image icon, a 404, or a page of HTML, every card built from it is broken too, no matter how good the tag looks in the source.

Then stop guessing and let a card debugger tell you what the scraper actually received: opengraph.xyz or metatags.io for a fast visual, Facebook’s Sharing Debugger and LinkedIn’s Post Inspector for the two platforms that cache hardest, and Google’s Rich Results Test for the JSON-LD. What they report is frequently not what your browser renders.

Do not let the page write its own summary

A description scraped from the first paragraph is usually navigational junk — an address, a tagline, a menu. Write one sentence per page by hand, under about 155 characters. If your theme lets you set it per page, set it. If it does not, a few lines of code can do it for every page at once.

Two rules make the hand-written version worth the time. First, say what the page is for rather than what it is about — “Book a Denver web audit” beats “Welcome to our website.” Second, keep it different on every page. The same description repeated across twenty pages tells a search engine those twenty pages are one page, which is the opposite of what you want it to conclude.

On WordPress the practical order is a per-page field for anything that matters and one template-level fallback for the long tail. Drop this in functions.php if you have no SEO plugin and want the fallback anyway:

add_action('wp_head', function () {
  if (is_singular()) {
    $desc = wp_strip_all_tags(get_the_excerpt());
    $desc = wp_trim_words($desc, 25, '');
    echo '<meta name="description" content="' . esc_attr($desc) . '">' . "\n";
  }
});

It is not clever, and it is not a replacement for writing the sentence yourself. It is the difference between a page having something in that slot and having nothing.

Sitemaps and the plumbing

A sitemap is a declaration: here is every URL I consider worth indexing. Check that yours actually returns XML instead of an empty response or a page of theme markup, then make sure robots.txt points at it. A sitemap nobody is told about is a hobby.

The file itself is boring on purpose:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

WordPress generates one at /wp-sitemap.xml on its own; most SEO plugins replace it with /sitemap_index.xml. Either is fine, provided it is reachable. Test the URL directly and read the content type:

curl -sI https://example.com/wp-sitemap.xml | head -n 5

You want a 200 and an XML content type. A 301 to a login page, a 404, or a 200 serving your theme’s HTML all mean the same thing: nothing is being declared. Then point crawlers at it from robots.txt, one line, lowercase key:

Sitemap: https://example.com/wp-sitemap.xml

Finally, submit it once in Google Search Console. The sitemap is the submission mechanism; Search Console is where you find out whether the URLs inside it were accepted. A sitemap that lists pages you have set to noindex is not an emergency, but it is a contradiction worth knowing about — you are asking to be indexed and asking not to be indexed in two different files.

The test that matters

Paste your own URL into a chat window and look at what appears. That card is your first impression for most of the internet, and it is the one thing visitors will never thank you for getting right.

Do it in more than one place, because the platforms disagree. Slack, Discord, iMessage, WhatsApp, LinkedIn and Facebook each pick a different combination of tags and crop the image to their own shape — the same 1200×630 file can read clearly in one and lose its edges in another. Send the link to yourself; do not trust a preview builder’s mockup over the real render.

Then expect the last failure mode: caching. Facebook and LinkedIn keep a copy of a page’s metadata for days or weeks. When you fix an image and the old grey box is still there, you have not failed — you just have not been re-scraped. The Sharing Debugger and the Post Inspector both have a forced re-scrape button, and that button is the entire fix.

Metadata is the part of your site that keeps working when nobody is looking at your design.