You paste your new post’s URL into LinkedIn and get back a bare blue link. No image, no headline, nothing that would make anyone click. Or worse, you get a preview built from whatever image happened to be sitting in your footer three years ago.
This isn’t a LinkedIn bug and it isn’t a WordPress bug. It’s a gap. WordPress publishes your content beautifully and then tells social platforms almost nothing about it, because the metadata those platforms read comes from a separate standard that core doesn’t output. Something on your site has to supply it, and if nothing does, every platform falls back to guessing.
Below is what the Open Graph protocol actually requires, the image specs Facebook and LinkedIn publish (they don’t match), why your fix won’t appear immediately even after you make it, and how to check any of this in about thirty seconds.
WordPress Core Emits No Social Tags At All
Grep a current WordPress install and you’ll find that core never emits og:title or twitter:card. We checked on a live WordPress 7.0.2 install while writing this: zero files under wp-includes output either one. Your theme’s wp_head() call fires, plugins hook into it, and unless one of them is an SEO plugin doing social output, the page goes out with a <title>, a meta description if something wrote one, and no social metadata whatsoever.
There’s an interesting wrinkle, though. The only Open Graph strings in wp-includes belong to a REST endpoint that reads them from other people’s pages. It’s the endpoint behind the block editor’s link previews, its docblock cites ogp.me directly, and it pulls og:image out of a remote page so it can show you a rich preview when you paste someone else’s URL. So the concept isn’t foreign to WordPress at all. Core just consumes it and doesn’t produce it, which is a fair architectural call and a bad surprise if you assumed it was handled.
What actually happens when the tags are missing
Each platform improvises, and they improvise differently. One scrapes the first reasonably-sized image in your DOM. Another falls back to the <title> and nothing else. A third caches whatever it found on the very first request and hangs onto it. That’s why the same URL can look correct in a Slack unfurl, half-right on Facebook, and completely blank on LinkedIn — you’re watching three different fallback heuristics run against a page that gave none of them a straight answer.
Every share of your URL — by you, by a customer, by a salesperson pasting it into a DM — renders from these tags. You wrote the page, you chose the image, and then a platform’s fallback logic decides how it looks to a few hundred people. Seven meta tags in your <head> take that decision back, and they’re the same seven tags on every page you’ll ever publish.
The Four Tags Open Graph Requires
The Open Graph protocol is documented at ogp.me, and it’s refreshingly short. The spec says you add <meta> tags to the <head> of your page, and it names exactly four as required for every page:
og:title— the title of your object as it should appear within the graphog:type— the type of your object, such asarticlefor a blog post orwebsitefor a landing pageog:image— an image URL representing your objectog:url— the canonical URL of your object, which the spec describes as the permanent ID used in the graph
That last one deserves a second read. og:url isn’t decorative, it’s an identity key. If your post is reachable at both a www and a non-www address, or over both http and https, and og:url disagrees between them, you’ve handed the platform two objects instead of one, and any engagement counts split accordingly. It should match your canonical exactly, every time.
The fifth tag that isn’t technically required
Open Graph lists og:description as optional but generally recommended, which undersells it badly. It’s the sentence under your headline in the preview card. Skip it and the platform either shows nothing there or scrapes something arbitrary out of your page body. Write it deliberately, treat it like the meta description’s louder sibling, and don’t assume it’ll inherit anything.
Two more worth adding even though nothing demands them: og:site_name, which puts your brand on the card, and the twitter:card declaration, usually set to summary_large_image when you want the big banner treatment rather than a thumbnail.
The Image Is Where Everyone Gets Burned
Nearly every broken preview traces back to the image, and the reason is that the platforms publish different numbers and nobody reads both.
What Facebook publishes
Meta’s own webmaster documentation on images in link shares is specific. The minimum allowed image dimension is 200 x 200 pixels, and the file must not exceed 8 MB. It recommends images at least 1200 x 630 pixels for the best display on high resolution devices, and sets a practical floor: at minimum you should use images that are 600 x 315 pixels to display link page posts with larger images. Below that threshold the image still shows up, it’s just rendered much smaller. The docs also ask you to keep the image as close to a 1.91:1 aspect ratio as possible so nothing gets cropped in Feed.
There’s one requirement in that document that has nothing to do with pixels and bites people on hardened servers: the crawler only accepts gzip and deflate encodings, and the docs simply tell you to make sure your server uses the right encoding. If your CDN or origin negotiates something else for a bot with an unfamiliar accept-encoding header, that’s a plausible cause of a failed fetch that has nothing to do with pixels — and you can lose an afternoon adjusting image dimensions that were never the problem.
LinkedIn’s numbers are not Facebook’s numbers
LinkedIn’s help documentation requires og:title, og:image, og:description and og:url, then publishes its own image rules: a maximum file size of 5 MB, minimum dimensions of 1200 (w) x 627 (h) pixels, and a recommended 1.91:1 ratio. Note the 5 MB ceiling against Facebook’s 8 MB, and the 627 against 630. Neither difference matters if you just ship a 1200 x 630 image, which clears both, and that’s exactly why 1200 x 630 became the de facto standard rather than anything either company mandated.
LinkedIn adds a rule the others don’t. In an “Important to know” callout on the same help page, it states that images less than 401 pixels wide display as a thumbnail image. That’s the cliff behind most “why is my LinkedIn preview so small” complaints. The callout isn’t explicitly scoped and sits near LinkedIn’s ad specs, but it’s the only published width threshold LinkedIn gives, and any image under it is liable to drop to the small layout however good it looks.
X is the one to stop guessing about
Card documentation for X has moved repeatedly, and several of its historical URLs now return 404s — we hit three dead ones checking this article. So be skeptical of any specific pixel spec you find quoted for it, including in posts more confident than this one. The durable move is to ship correct Open Graph tags plus a twitter:card value and let the platform read what it reads, rather than optimizing against numbers that may have been true in 2019.
Export at 1200 x 630 pixels, keep it under 5 MB, and use JPG or PNG. That satisfies Facebook’s 1200 x 630 recommendation, clears LinkedIn’s 1200 x 627 minimum and its 5 MB ceiling, lands on the 1.91:1 ratio both ask for, and stays well clear of LinkedIn’s 401-pixel thumbnail cliff. Keep the readable text inside the middle two-thirds so nothing important sits where a crop would land.
Getting the Tags Onto a WordPress Page
Two honest routes, and the plugin one is right for most sites.
Let your SEO plugin do it
Yoast, Rank Math, SEOPress and All in One SEO all output Open Graph and card tags, typically defaulting og:title to your SEO title, og:description to your meta description, and og:image to the post’s featured image. If you already run one of these, your tags probably exist — go verify what values they’re carrying rather than installing anything else.
And verify is the operative word. While writing this we checked amplifi.studio’s own blog and found our og:image resolving to a 488 x 294 screenshot. Not missing, not broken, technically present and correctly formed — and comfortably under Facebook’s 600 x 315 floor for the large layout. The plugin was doing exactly what it was configured to do with the featured image it was handed. Nobody had ever looked at the number.
Or write it yourself in functions.php
If you’d rather not add a plugin for seven tags, hook wp_head and print them. WordPress gives you everything you need: get_the_post_thumbnail_url() returns the featured image URL at a registered image size (or a flat width/height array), and returns false if the post has no featured image — pass a size that isn’t registered and you get the original image URL back instead, which is worth knowing before you accidentally hand a platform a 4MB original. get_permalink() gives you the canonical address. Guard the whole thing with is_singular() so you’re not emitting article metadata on your archives, escape every value on output, and pick a sensible sitewide fallback image for posts that have no featured image. Twenty lines of PHP, no dependency, and you own the behavior.
Whichever route you take, set an explicit fallback. A post with no featured image and no default is the single most common cause of a blank card, and it’s the one failure mode that looks like the tags aren’t working at all.
If the blocker is that you’ve got four hundred posts with thin or missing titles and descriptions feeding those tags, that’s a bulk problem, not a per-post one. amplifi.meta is part of our open source WordPress suite and generates SEO titles and meta descriptions across a whole library with AI, with a human approving each one. It’s free, and the source is public.
View on GitHubWhy Your Fix Doesn’t Show Up
You add the tags, reshare the link, and get the old broken preview back. Nothing is wrong. Meta’s documentation states it plainly: when content is shared for the first time, the crawler scrapes and caches the metadata from that URL, and the crawler has to see an image at least once before it can render it. So the first person to ever share a piece of content won’t see a rendered image. The docs also note that updating the image for a URL won’t automatically update the preview on shares that already exist — those have to be refreshed.
The documentation names three ways around it. Run the URL through the Sharing Debugger to pre-fetch the metadata, which also updates an image you’ve changed. Force-scrape the URL programmatically through the Graph API. Or include og:image:width and og:image:height tags, which tell the crawler the dimensions up front so it can render immediately instead of downloading and processing the image asynchronously. That third one is the cheapest and it’s the one people skip, because it’s the only fix that lives in your markup rather than in a tool you have to remember to open.
Check before you publish, not after
Every platform ships a free inspector, and running one takes less time than reading this paragraph. Meta’s Sharing Debugger shows what its crawler sees and lets you force a re-scrape. LinkedIn’s Post Inspector does the same for LinkedIn’s cache. Between the two you’ll catch a missing tag, a wrong image, or an og:url pointing somewhere unexpected before anybody sees the bad version.
One caching detail from the same Meta docs is worth internalizing: images are cached against each image’s URL. Overwrite hero.jpg in place with new artwork and the crawler may keep serving the old one indefinitely. Publish the replacement at a new URL instead, and don’t delete the old file — Meta warns there may be existing stories still referencing it. A rescrape refreshes the page’s metadata; it doesn’t necessarily refresh an image file it already believes it knows.
Frequently Asked Questions
Pick your most-shared page, run it through the Sharing Debugger and the Post Inspector, and see what the crawlers actually have. Whatever comes back, you’ll learn something in under a minute — and if the answer is embarrassing, you’re in good company.
Built by amplifi.studio — see also Google Thinks You Copied Yourself: A WordPress Canonical URL Guide.