The share card is the first impression, so it should look like you

Start from the traffic reality: when a link gets shared, the preview card is rendered for everyone who sees that share, while only a fraction click through to the actual page. Across all the times a given page's link travels through messages and feeds, the card racks up far more impressions than the page ever will. The thing you spent your effort on — the page — is the part fewer people see. The thing you probably ignored — the card — is the part most of them see. The attention is inverted relative to where the effort went.

Once that inversion is clear, the priority shifts. The card isn't a nice-to-have afterthought bolted onto a finished page; it's arguably the more important surface, because it's the one doing the first-impression work at scale. A brilliant page behind a generic card is a well-set table behind a broken front door — most people judge the door and never come in. Treating the card as a first-class output, not a byproduct, follows directly from counting who sees what. It's the same reasoning that made me build real thumbnails for every project on my network page — the small visual stand-in is the thing most people actually judge.

The preview card is seen by everyone who scrolls past the share; the page only by the few who click. You optimized the part fewer people see.

The specific harm of a default card is what it communicates. A generic, auto-filled preview — mismatched image, no design, a bare title — reads as machine-generated, and machine-generated reads as nobody-cared. It signals that there's no person behind this, no attention, no craft, right at the moment someone is deciding whether to click. Even if the page behind it is excellent, the card has already set an expectation of carelessness, and first impressions are expensive to overturn.

A card that matches the look of the actual site does the opposite. It says the same person who made the thing made the door to the thing, and the whole experience is considered. That coherence — the card looking like it belongs to the site, sharing its typography and palette and mood — is a quiet, powerful signal of care. It tells someone, before they've clicked anything, that attention was paid here, which is exactly the impression you want to make first.

I learned all of this the embarrassing way. I texted a link to my own site — andrewjpyle.com — and the preview came up blank. Just a bare title where the card should be. The Open Graph meta tags were all correct; they pointed at /og/og-default.jpg. The problem was that the file didn't exist. It had been listed as a to-do and never committed, so every share of my site, on every platform, had been unfurling to a broken image for who knows how long. The most-seen version of my work was a 404.

The maddening part is that everything looked fine from where I stood. The tags validated, the code was correct, nothing errored. The failure existed only at the surface no dashboard watched — the rendered card in someone else's messaging app. That's the trap with share cards specifically: you don't share your own links to yourself, so the maker sees them approximately never while the audience sees them constantly. A broken one can sit there silently for months while you feel perfectly polished.

Fixing it happened in stages, and the stages are the whole lesson. First I made the missing images exist, so the card stopped being blank. But what I'd shipped was on-brand for a brand I no longer used — an old command-deck palette, the wrong typeface — so a second pass rebuilt it to match the site as it actually looks now. Getting from 'broken' to 'present' to 'actually looks like me' took three separate commits, and only the last one delivered the thing I wanted.

The version I settled on is per-page cards designed in the same visual language as the site itself — the same dark, near-black background, the same warm amber, the same Instrument Serif headline over DM Sans, so a shared link looks like a piece of the site broke off and traveled. Per-page matters because different pages deserve different first impressions; a single sitewide card for everything is better than the default but still generic across your own work. A card tuned to the specific page tells the specific truth about what's behind the link — the same editorial instinct that says a link should be placed where the idea actually connects.

So the network page gets a card that says network, and each work project gets its own topic card. This is fiddly, unglamorous work — making sure the right image exists, at the right 1200×630 dimensions, for each page. It's easy to skip because no single card feels urgent. But the aggregate is the most-seen face of the whole body of work, and getting it coherent pays off in an impression you never directly watch being made. The people forming an opinion of your work from a card in a feed are numerous and invisible, and the card is the only thing you get to say to them.

The mechanism that keeps per-page cards from being misery is that I don't hand-design each one. A single HTML template reads its kicker, title, and description from the URL's query string, so one file drives every card. To make a new card I point it at the page's text, render the template at exactly 1200×630 with headless Chrome, and screenshot it to an image. The design lives in one place and the cards are just that design filled in with different words — the same one-engine-many-outputs move I lean on everywhere else.

# one template + a query string -> a per-page card
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --hide-scrollbars \
  --force-device-scale-factor=2 --window-size=1200,630 \
  --screenshot=out.png \
  "file://$PWD/card-template.html?kicker=NETWORK&title=Network&desc=..."

# then flatten to a real 1200x630 JPG the SSG build serves at /og/
sips -s format jpeg -Z 1200 out.png --out client/public/og/og-network.jpg

Because the template is real HTML using the site's actual fonts and color tokens, the card can't quietly drift out of sync with the site. And there's a subtlety that makes all of this matter: the scrapers that build these previews don't run JavaScript. They read the raw HTML my server sends and stop. So the og:image tag has to be present in the static HTML at build time, not injected by the app after it loads — which is why I prerender the site into real HTML for crawlers rather than trust a preview bot to run my React.

The broader lesson I took from this is to put polish where the attention actually is, not where I assume it is. It's natural to lavish care on the page because that's where I spend my time building — but the audience's attention is distributed differently than my effort is, and the honest move is to follow the eyes. Craft gets spent on surfaces the maker sees constantly and the audience barely does, while the surface the audience sees most gets whatever the tooling produced by default — the same blind spot as trusting a homepage number I put there myself over the version a visitor actually loads.

Share cards are the clearest example of that mismatch, which is why they're worth the trouble. The fix isn't more work on the page; it's redirecting a little care to the preview doing the first-impression work at scale — and building the machinery so that care costs almost nothing per page after the first. Make the most-seen version of your work look like you meant it, and you've upgraded the impression for the majority who never make it to the page — which, it turns out, is most of the point of shipping the page at all.