Why LinkedIn wouldn't preview my site

Summary

• Symptom: "We couldn't generate a preview for this link", in the Featured section and in the post composer, on desktop and on mobile.
• Cause: most likely a reputation block on the shared pages.dev hostname the site was served from. That is an inference from a controlled test, not something LinkedIn confirmed — I cannot see inside their systems.
• Fix: moved the identical site to a domain I own. The preview appeared immediately.
• Confirmed: 25 September 2026, preview rendering in the Featured section.

Ruling out the page

A missing preview is usually the page's fault, so that is where I started. Everything checked out:

• robots.txt allows all crawlers.
• A request with LinkedIn's crawler user agent got a 200 with every Open Graph tag present.
• The preview image is a 1200×630 RGB PNG with no alpha channel.
• No redirects, no noindex, around 150 ms to first byte.
• The page is static HTML: about 19,000 characters of content render with JavaScript off, so a crawler that does not execute scripts loses nothing.

Then the decisive check: LinkedIn's Post Inspector fetched the URL and rendered the title, description and image correctly.

The pattern that mattered

The scraper worked. Every place a person could actually share the link refused it.

If the page were broken, the inspector would have failed too. A tool that reads the page fine, sitting next to a product that will not show it, means something between them is judging the URL rather than the content. At that point, more page debugging was wasted effort.

The site was served from nick-farrugia.pages.dev. That suffix is shared by an enormous number of sites, including abusive ones, and a platform deciding which links to unfurl has good reason to be wary of it.

A control, not a theory

To test that rather than argue it, I changed exactly one variable: the same files, with the same headers, served from a subdomain of a domain I already owned.

The preview appeared immediately. Nothing about the page changed, only its hostname — about as clean a result as a black-box system allows.

Moving to a real domain, and the trap in the middle

I registered nickfarrugia.dev. The registrar was not Cloudflare, which added a step that is easy to get subtly wrong.

Freshly registered, the domain sat on the registrar's parking service, presenting a certificate issued for the registrar's own hostnames. Browsers reported ERR_CERT_COMMON_NAME_INVALID — and because .dev is on the HSTS preload list, Chrome offers no way to click through. The domain was unreachable, not merely ugly.

The order that works:

1. Add the zone to Cloudflare.
2. Change the nameservers at the registrar.
3. Wait for the zone to show Active.
4. Then attach the domain to the Pages project under Custom domains.

"Active" is not "serving". Between steps 3 and 4, the TLS handshake completed with a perfectly valid certificate and the HTTP request then hung, returning zero bytes. Cloudflare had imported the registrar's parking records when the zone was added, and was proxying the hostname to them. A valid certificate on a dead connection is a misleading combination — it looks like a slow origin rather than a misrouted one. Attaching the custom domain pointed the hostname at the project, and it was serving about twelve minutes later.

The cleanup nobody plans for

The site's own origin appeared in 23 places across five files — canonical, Open Graph, hreflang, the sitemap. Those were already behind one script with a consistency check, so the site itself moved in a single command.

The CV did not. It is generated from a separate data file, and carried the old hostname in six more places the script never looked at. A domain change is a repository-wide search, not a site-wide one.

What I'd keep

• When the debugging tool works and the product does not, stop debugging the input. The disagreement between them is the finding.
• Change one variable. A control domain turned a plausible theory into a result in minutes.
• Check the step after "done". Zone active, certificate valid and site working were three different states.
• Own the URL you put on a CV. A link meant for strangers should not inherit anyone else's reputation.