Branded short domains: the four things that break link previews

The short domain resolves and the click lands on the right page. Then you paste that link into a post and the card comes back as bare blue text, no image, no title. Nothing errored. A working link and a blank preview card can both be true at once, because the browser that followed your click and the scraper that built the card made different requests and forgave different problems.

The setup instructions end where the problem starts

A branded short domain setup is short. You point a CNAME or an A record at your link vendor, verify the domain in its dashboard, and the vendor starts answering for that hostname. A successful click proves two things: DNS resolves the short host, and the redirect rule sends you onward. It proves nothing about the preview path.

A link preview scraper is a separate, non-browser client. It sends different headers, will not follow a chain as far as a browser will, caches what it got, and fails into a blank card rather than an error. This is not a setup tutorial. What follows is four reasons the preview breaks once the click works, in the order worth checking.

A redirect chain longer than one hop

The chain people assume they have is short domain, then destination. The chain they often have is short domain, then the vendor’s own redirect endpoint, then the destination URL. Two redirects, and nobody clicking through notices.

Run curl -I -L against the short URL and read every status line and Location header in order. Here is a real chain, run on 6 September 2026 against a documentation host, not a link vendor:

curl -I -L -A “Mozilla/5.0” http://developers.cloudflare.com/ssl/edge-certificates
HTTP/1.1 301 Moved Permanently
Location: https://developers.cloudflare.com/ssl/edge-certificates
HTTP/2 307
location: /ssl/edge-certificates/
HTTP/2 200

Two redirects for one page, one for the protocol upgrade and one for the trailing slash, neither visible to a human. A short domain handing off through a vendor redirector has the same shape, and if the destination adds a slash you are at three. The fix is mechanical: collapse to a single 301 or 302 hop where the vendor allows it, or get the vendor to confirm the short domain rule is a direct one hop redirect, not a pass through their shared redirector. No platform publishes a hard hop limit, so treat every hop removed as risk removed rather than aiming at a number.

A missing certificate on the short host

Pointing DNS at a vendor and that vendor holding a certificate for your exact short hostname are separate events. A certificate covers a specific list of names. Checked on 6 September 2026, the certificate on ogp.me carries a Subject Alternative Name list of exactly two entries, ogp.me and www.ogp.me. A third name pointed at that host is not covered, however correct the DNS record is.

Cloudflare’s Universal SSL documentation draws the same boundary. On a full setup it covers the root domain and first level subdomains. On a partial CNAME setup, each proxied subdomain gets its own certificate. The same page states those certificates are issued after the domain is active. Issuance follows activation, and that gap is where a redirect works while the certificate does not exist yet.

Browsers hide this, through a reused connection or an interstitial clicked past weeks ago. A scraper has no history with your domain, so its handshake completes or it does not. Run curl -v against the short host, or openssl s_client -connect your.short.domain:443 -servername your.short.domain piped into openssl x509 -noout -ext subjectAltName. Read the SAN list, not the subject line. Either your hostname is there or the certificate belongs to the vendor.

Meta tags that live only on the final URL

The Open Graph protocol specification is explicit about where tags live. You turn a page into a graph object by adding metadata to that page, placing meta tags in its head, with four required properties: og:title, og:type, og:image and og:url. It defines og:url as the canonical URL of the object, used as its permanent ID in the graph. Tags are a property of a document. A redirect is not a document.

The failure is concrete. Your destination page has perfect tags. Your short URL returns a 301 with a Location header and an empty body, so there is no head element and no og:image on the URL actually pasted. If the scraper follows through to the destination, the card renders. If it stops at that first response, times out, or caches it, the card stays empty until something forces a fresh read.

Separate this from the redirect problem. A single clean hop still produces a blank card if the intermediate empty response is what got cached. Slack documents a cache window of roughly thirty minutes for its link expanding robot, so a bad first read outlives the fix.

A host that answers scrapers differently than browsers

The fourth cause cannot be found by clicking, which is why nobody finds it. A CDN rule, a fingerprinting layer, or a security plugin can key off the user agent, the header set, or the request pattern and hand a non-browser client a challenge page, a block, or a different redirect. No error surfaces to a human. Here are four requests run on 6 September 2026 against one URL, the front page at reddit.com, identical except for the user agent:

  • A full Chrome 124 desktop string: HTTP 200, 8,397 byte body
  • The bare string “Mozilla/5.0”: HTTP 403, 1,522 byte body
  • “curl/8.0”: HTTP 200, 8,397 byte body
  • Slack’s documented link expanding robot string: HTTP 200, 3,872 byte body

One host, one URL, three outcomes, decided by a header and nothing else. A marketing site behind a WAF can sort clients the same way.

Slackbot-LinkExpanding 1.0, the robot Slack documents for link previews, responds to links users post into channels, fetches as little of the page as it can using HTTP Range headers, and looks for oEmbed and Twitter Card or Open Graph tags. Each is a place a host can quietly fail one: blocking the unfamiliar user agent, mishandling the ranged request, or pushing the tags past the slice the robot read.

The diagnostic is a comparison: fetch the short URL with a browser user agent, then with a documented crawler string, printing only status and size with curl -s -o /dev/null -w “%{http_code} %{size_download}” -A “<user agent>” “$URL”. If the two differ, the cause is a rule on your own edge, not a platform bug.

Checking a link before it goes out, not after

  1. Run curl -I -L on the short URL first. Fastest check, and it catches two of the four causes at once. Count hops, read each status code, and watch for a handshake failure.
  2. Confirm the hostname is on the certificate. If curl -v is ambiguous, run openssl s_client against the short host and read the SAN list for your exact hostname.
  3. Put the URL through Meta’s Sharing Debugger. The point is to see the response a platform’s own crawler received, not what your browser renders. [EVIDENCE NEEDED: Meta’s documentation of what the Sharing Debugger reports and how to force a re-crawl. Its developer pages returned HTTP 400 to automated requests during drafting, so nothing about the tool is quoted here.]
  4. Run it through LinkedIn’s Post Inspector if LinkedIn matters here. It is served at linkedin.com/post-inspector, which returned HTTP 200 on 6 September 2026, though the interface renders client side and a plain fetch returns no readable description of its output. [EVIDENCE NEEDED: LinkedIn documentation stating what the Post Inspector reports and whether it forces a re-scrape.]
  5. Force a fresh read after every fix. Caching is why causes two and three look identical from outside, and a tool still showing a broken card after a fix may be serving a cached result.

Where to go next on the link stack

If you are auditing the whole link stack, the adjacent problems are tracking and measurement. There is a companion piece on a UTM convention that survives a handoff, and one on QR code scan limits. If the question becomes whether to pay for a shortener, the link management pricing breakdown covers meters and tiers without picking a winner.

Sources here were fetched and verified on 6 September 2026, and the curl output above reproduced in that session. This is a diagnostic post, not Watchdog data, and it is not on the re-verification schedule. followedapp is published by the team behind RecurPost, covered vendor #34 under the same rules as every other vendor.

FAQ

Why does the link work fine when I click it, but the preview card is blank?

Clicking only tests the browser path. The card is built by a separate, non-browser request from a platform’s link crawler, which can fail on any of the four causes above. A browser tolerates a longer chain, reuses a cached TLS session, follows through to the destination for the tags, and sails past a bot rule that never applied to it. The crawler does none of that reliably, and it fails into a blank card, not an error.

Does the short domain need its own SSL certificate, separate from the destination site’s certificate?

Yes. A certificate is matched against the exact hostname the client asked for, so the short domain needs coverage for that name and the destination’s certificate does nothing for it. Cloudflare’s Universal SSL covers only the root domain and first level subdomains on a full setup, and states certificates are issued after the domain is active. The redirect can answer in a browser before the certificate exists.

Sources

Scroll to Top