Preview a link
Fetched once from the edge as a browser would. The og:image is fetched too, to measure it. Ten checks a minute per IP.
How it works
Fetch
The page is requested from the edge with a browser user-agent, following redirects, and the first 256 KB of HTML is parsed.
Read
Title, meta description, every og: and twitter: tag, canonical, favicon, robots meta and X-Robots-Tag, lang, H1 and JSON-LD blocks are extracted.
Measure
The og:image is fetched and its dimensions read from the file header — PNG, JPEG, GIF, WebP — along with size and content type.
Render
Four cards are drawn with the fallback rules each platform uses, and every gap becomes a finding with the tag to add.
The first impression is usually a card
A prospect who is interested does not click the link in your email; they paste it into Slack to ask a colleague. The colleague sees a card, or a bare URL, and decides in a second whether it is worth opening. LinkedIn is the same when someone shares your case study, and a mail client shows a preview when the link is forwarded. The card is built from five or six meta tags, and most landing pages have some of them. This shows you which, and what each platform does about the ones that are missing.
Fallbacks differ by platform
Slack, LinkedIn and Facebook read Open Graph first and fall back to <title> and the meta description. X reads twitter: tags first, then OG — but without a twitter:card tag it draws a small square card even when a 1200×630 og:image is there. iMessage and mail clients want og:image and a title and ignore the rest. Google uses none of the OG tags; it shows the title and meta description, or invents both from the page. The four cards in the results follow those rules, so a page can look right in one and broken in the next.
The image is where it breaks
A relative path in og:image works in the browser and fails in every unfurler. An http:// image will not load on an https page. Anything under 600×315 gets a thumbnail or nothing; anything not close to 1.91:1 gets cropped; SVG is never rendered; over 5 MB and LinkedIn gives up. The tool fetches the image itself and reads the dimensions from the file, because the og:image:width tag says what the developer believed, not what is there. If the image fails here, it fails on the platforms.
After you fix it
Facebook, LinkedIn and Slack cache what they scraped the first time, for days. Changing the tags does nothing for a link that has already been shared until you force a re-scrape — Facebook's Sharing Debugger and LinkedIn's Post Inspector both have a button for it — or share a URL with a changed query string. Re-run this check after the fix and after purging your own cache; the finding list should be empty except for the optional items.
Frequently asked questions
Why does the preview here look different from what Slack showed?
Slack cached its version when the link was first shared. This tool fetches the live page. Fix the tags, then re-share with a query string or wait for the cache to expire.
What size should og:image be?
1200×630 pixels, 1.91:1, PNG or JPEG, under 300 KB. That renders sharp on every platform. 600×315 is the minimum for a large card.
Do I need both og: and twitter: tags?
You need og:title, og:description and og:image for almost everything, plus twitter:card=summary_large_image so X shows the big card. Twitter title and description tags are optional; X falls back to OG.
Does the check run as a real browser?
It fetches the raw HTML from the edge with a browser user-agent, which is what unfurlers do. Tags injected by JavaScript after load are not seen by any of them, and not by this tool.
Why is noindex flagged when I only care about previews?
Because it is easy to leave on a page after launch, and it takes the page out of Google entirely. Previews still work with noindex, so nothing else in the results changes.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.