guides

LinkedIn link preview not showing — the 9 causes (and the Post Inspector workflow that fixes most of them)

the linkboo team·32 min read·updated Mon Jun 01 2026 17:00:00 GMT-0700 (Pacific Daylight Time)
On this page

You shared a link in a LinkedIn post and the preview is wrong. The old image is showing, the title is from last year, the description is generic, or there's no preview card at all — just a blue underlined URL.

You went to look it up and three of the first four articles told you to "use Post Inspector." You did. It worked, or it didn't. If it didn't, you're back to Google.

This is the complete reference: nine distinct causes of a broken LinkedIn preview, the diagnosis path for each, the Post Inspector workflow as a four-stage flow (not a magic button), and the three LinkedIn-specific behaviors nobody else writes about cleanly — the 7-day cache TTL, the 5MB image cap, and the "first crawl wins" trap that needs a cache-bust query string to fully reset.

If you're also dealing with broken previews on Facebook or X, the Facebook equivalent of this problem and the X (formerly Twitter) equivalent — different cache, different tooling reality are the sibling articles. Each platform has its own crawler, cache, and quirks; the meta tags overlap but the failure modes diverge.

When a link is shared for the first time — in a post, a profile bio, an InMail, a LinkedIn Newsletter, or via the Share dialog — LinkedIn's crawler hits the URL. It identifies itself as LinkedInBot/1.0 (compatible; Mozilla/5.0; Apache-HttpClient +http://www.linkedin.com). It reads Open Graph meta tags from your <head>, in priority order: og:image, og:title, og:description, og:url. If a tag is missing, it falls back — <title> for og:title, <meta name="description"> for og:description, no image if og:image is absent.

LinkedIn does not read twitter:* tags. It does not execute JavaScript meaningfully. And it documents the cache TTL as approximately 7 days on LinkedIn's official help-center page for previews — about a quarter of Facebook's ~30 days.

The cache is keyed by the exact URL string. https://example.com/page and https://example.com/page?ref=fresh are two different cache entries. The Post Inspector at linkedin.com/post-inspector/ is the only published way to force a cache refresh before the 7-day TTL ages out. Authentication is required — a personal LinkedIn account works; no Developer account needed.

Here is the architectural picture nobody else draws for you:

                  ┌──────────────────────────────┐
   Your page  ──► │  LinkedIn OG preview cache   │ ──► Feed posts (personal)
                  │  (~7-day TTL per URL)        │ ──► Feed posts (Company Page)
                  │  Keyed by exact URL string   │ ──► Profile bio link
                  │  First crawl writes the      │ ──► LinkedIn Newsletter
                  │  cache; subsequent crawls    │ ──► InMail / Share dialog
                  │  of the same URL resist      │
                  │  overwriting it.             │
                  └──────────────────────────────┘

LinkedIn's crawler is more cache-locked than Facebook's. Facebook's Sharing Debugger re-scrapes a URL any number of times within its ~30-day window. LinkedIn writes the first successful crawl into cache and resists later refreshes — by design, to prevent the clickbait pattern of posting a clean preview and swapping the destination after engagement accumulates. Post Inspector overrides this for the URL submitted, but a follow-up scrape of the same URL within a short window can still return the original cached result. This is the architectural fact that makes the LinkedIn-specific failure modes below behave the way they do.

diagnose first — match your symptom to the cause

Skim this. Find the line that matches what you're seeing. Jump to the cause section.

What are you seeing?
 ├─ No preview at all, LinkedIn shows just a blue URL
 │   → Cause 1 (missing OG tags) or Cause 2 (crawler blocked)
 │
 ├─ Preview shows old title/image; the page itself is updated
 │   → Cause 3 (cache not invalidated)
 │
 ├─ Wrong image appears (not the one in your og:image tag)
 │   → Cause 4 (image spec violation) or Cause 5 (duplicate tags)
 │
 ├─ Preview image is tiny, sideways, cropped weirdly, or pixelated
 │   → Cause 4 (image dimensions or aspect ratio wrong)
 │
 ├─ Post Inspector shows the right preview; new posts show the wrong one
 │   → Cause 6 (first-crawl-wins; query-string-bust required)
 │
 ├─ Preview renders correctly, but the post got ~30 impressions
 │   → Cause 7 (link suppression / low-quality classifier)
 │
 ├─ Desktop preview is correct; LinkedIn mobile app shows old preview
 │   → Cause 8 (mobile cache divergence)
 │
 ├─ Preview works from personal profile but breaks from Company Page (or vice versa)
 │   → Cause 9 (personal vs Company Page rendering / Sales Nav edge cases)
 │
 └─ Preview renders, but viewers tapping from LinkedIn mobile land logged-out
     → That's not a preview problem. That's the in-app browser logged-out problem.
       See: /guides/in-app-browser-logged-out and /for/linkedin

Every cause section below has the same shape: one-line symptom, why it happens, exact fix. The dedicated Post Inspector workflow walkthrough is its own H2 after the cause list.

cause 1 — your Open Graph tags are missing or malformed

Symptom. No preview. LinkedIn shows the URL as plain blue text, or composes a generic card from your page <title> with no image.

Why it happens. LinkedIn needs four tags inside <head> to render a rich card: og:image, og:title, og:description, og:url. A fifth tag — og:type — is recommended. Missing tags trigger clumsy fallbacks; malformed tags get skipped silently.

The minimum working set, copy-pasteable:

<meta property="og:title"       content="Your headline — under 200 chars for LinkedIn" />
<meta property="og:description" content="One or two sentences, under 300 chars." />
<meta property="og:image"       content="https://yoursite.com/og/your-image.png" />
<meta property="og:url"         content="https://yoursite.com/your-page" />
<meta property="og:type"        content="article" />

Per LinkedIn's developer docs for share buttons, this is the tag set LinkedIn reads. For Articles specifically, article:author and article:published_time are read if present. They are not required for non-Article pages.

Common malformations:

  • Tag placed outside <head> — the parser stops at </head>.
  • name= instead of property=. LinkedIn reads property for OG tags. The most common mistake on the internet.
  • Missing content= attribute, or content="".
  • og:url set to a relative path. Must be absolute HTTPS.
  • Duplicate tags from competing sources — see cause 5.

Verify with View Source, not Inspect Element. Inspect Element shows the post-JavaScript DOM. LinkedInBot doesn't execute that JavaScript. Open View Source on your published page, search og:, count each property. Each of the four required properties should appear exactly once.

WordPress note. Yoast, Rank Math, All in One SEO, and your theme can each emit OG tags. If two are active, you ship duplicates. Pick one source-of-truth and disable OG output in the others.

Headless CMS note. Next.js with both layout-level and page-level <head> writes, Astro with both layout <head> and page <head>, Nuxt with useHead overlaying server-rendered tags — all produce duplicates that LinkedIn resolves nondeterministically. Audit the head-merging path; the framework's metadata API (Next.js generateMetadata, Astro layout slot, Nuxt useHead) is the single source of truth.

cause 2 — LinkedInBot can't reach your page or your image

Symptom. Post Inspector reports a fetch error — "Unable to retrieve information for this link," a 4xx/5xx code, or a timeout. The preview is empty.

Why it happens. Something between the public internet and your origin is refusing the crawler's request. Six common variants.

1. robots.txt blocks LinkedInBot. Add an explicit allow:

User-agent: LinkedInBot
Allow: /

Worth allowing alongside, the other social-preview crawlers: facebookexternalhit, Twitterbot, Slackbot, Discordbot, WhatsApp, Pinterestbot, TelegramBot.

2. Firewall or WAF blocks Meta-style bot traffic. Cloudflare Bot Fight Mode, Sucuri, and AWS WAF classify LinkedInBot/1.0 as bad-bot traffic under default settings. LinkedIn doesn't publish a stable IP range; UA-based allowlisting is the practical approach. Whitelist the LinkedInBot user-agent string at your CDN/WAF.

3. HTTP basic auth, IP allowlist, or paywall. The crawler can't authenticate. Stage a public version of the page for the Post Inspector pass.

4. HTTPS / TLS issues. LinkedIn requires HTTPS for both the page AND the og:image. Self-signed certs, expired certs, broken intermediate chains, mixed-content URLs all silently break the crawl. Test at SSL Labs. Anything below an A rating risks failure. SNI must be configured correctly if the origin serves multiple hostnames.

5. Server response time. LinkedInBot's observed timeout is approximately 10–15 seconds. Slow first-byte responses produce silent crawl failures with no publisher-side error. CDN-cache your OG endpoints. If you generate OG images on the fly via a serverless function, verify cold-start latency stays well under 10 seconds — Vercel and Netlify cold starts on under-provisioned plans regularly exceed it.

6. The image specifically isn't reachable. Open the og:image URL in an incognito browser. If it doesn't render for a logged-out anonymous user, LinkedIn can't read it either. S3 buckets with restrictive bucket policies, image CDNs with Referer-gated access, signed CloudFront URLs that expire mid-cache, hotlink rules — all bite. Verify from terminal:

curl -A "LinkedInBot/1.0" -I "https://yoursite.com/og/your-image.png"
# expect: HTTP/2 200, Content-Type: image/png (or jpeg)

If curl returns 200 from your laptop and Post Inspector still can't fetch, you have an IP-level block somewhere upstream. The adjacent user-agent detection patterns cover the broader UA-detection family — same mechanic, different consumer.

cause 3 — LinkedIn's preview cache hasn't refreshed

Symptom. You updated the page. Post Inspector returns the old preview. New posts in the feed show the old preview.

Why it happens. LinkedIn caches the parsed OG data for approximately 7 days per URL — confirmed in LinkedIn's help-center documentation. The cache does not auto-invalidate when your page changes. Until you force a refresh or wait out the TTL, every new post draws from the stale cached object.

The fix. Run the URL through Post Inspector and re-submit. The first inspection invalidates the cache entry; the parsed output reflects the fresh fetch. The dedicated Post Inspector workflow walkthrough below covers the four stages in order.

Why the cache exists at all. LinkedIn locks the first crawl to prevent a specific clickbait pattern: post a benign-titled preview, accumulate engagement, then swap the OG tags so the now-popular post drives traffic to something different. The aggressive cache lock is the platform's defense. Useful to know — because the behavior in cause 6 below is the same defense viewed from the other side.

What Post Inspector does NOT do. It does not retroactively update previews on posts already published. Existing posts in the feed continue to show the cached preview from when they were first posted, forever — there is no LinkedIn affordance to update a previously-rendered card. The only fix for a wrong preview on an existing post is to delete the post and re-publish with the refreshed preview.

If Post Inspector shows the correct preview but new posts still show the old one, you have a different problem — see cause 6.

cause 4 — your og:image violates LinkedIn's spec (the 5MB / 1200×627 reality)

Symptom. No image in the card, a downscaled blurry image, the wrong image, or a small thumbnail where you expected a hero card.

Why it happens. LinkedIn has strict image rules, and the spec is meaningfully different from Facebook's. Quiet violations cause silent fallback.

Constraint LinkedIn spec What happens if violated
Width × height (recommended) 1200 × 627 (1.91:1) Rendered smaller; image may be cropped from center
Width × height (minimum) 200 × 200 Image rejected; generic fallback or no image
Aspect ratio 1.91:1 ideal Square (1:1) renders as a small thumbnail; 16:9 close enough
File size (recommended) <1MB Fast crawl, reliable render
File size (LinkedIn maximum) 5MB LinkedIn drops above 5MB silently
Format JPG, PNG, GIF (static) WebP supported but unreliable in feed cards
URL type Absolute HTTPS Relative URLs and HTTP-only URLs fail
Access Publicly accessible — no auth, no Vary-by-cookie, no referer rules 401/403/404 on crawler IP breaks scrape
Content-Type header image/png, image/jpeg, image/gif text/html (404 page) or application/octet-stream rejected
CDN/origin Direct HTTPS path; no signed-URL expiry mid-cache window Signed S3/CloudFront URLs that expire mid-cache cause silent breakage

The 1200×627 vs 1200×630 nuance. Facebook recommends 1200×630. LinkedIn officially recommends 1200×627 — three pixels of height difference, sourced from LinkedIn's Marketing Solutions blog on share-link images. Most articles inherit the Facebook spec and never name the distinction. In practice, 1200×630 works on LinkedIn — the difference is small enough that LinkedIn doesn't reject. But if you are per-platform optimizing, the canonical LinkedIn spec is 627, and the cleanest pattern is to ship one image at 1200×627 that satisfies both platforms.

The 5MB hard cap. LinkedIn drops og:image files above 5MB. Facebook tolerates up to about 8MB; LinkedIn is meaningfully stricter. Most modern build pipelines (Next.js next/image, Astro <Image />, the Cloudinary URL grammar) can output images above 5MB if you've configured large source images and high-quality settings. For og:image specifically, override to a hand-optimized JPG or PNG well under 1MB. Verify:

curl -I "https://yoursite.com/og/your-image.png"
# Content-Length should be < 5,000,000 — ideally < 1,000,000

The WebP gotcha. LinkedIn technically supports WebP as of 2024+ updates, but feed-card rendering is intermittently broken on Android specifically as of 2026 — observed, not officially documented. JPG and PNG are the predictable choices. If your build pipeline auto-generates WebP, override for og:image:

// app/blog/[slug]/page.tsx — Next.js
export async function generateMetadata({ params }) {
  return {
    openGraph: {
      images: [{
        url: 'https://yoursite.com/og/post-cover.jpg',  // static JPG, not /_next/image WebP
        width: 1200, height: 627, alt: 'Post cover',
      }],
    },
  };
}

Versioned image paths. Treat every new og:image as a new URL. Serve it at a stable, versioned path (/og/post-cover-v2.jpg, not /og/post-cover.jpg?t=12345), so CDN caching of the image itself doesn't fight your preview-cache refresh strategy.

LinkedIn HEAD-budget note. LinkedIn does not document a strict head-parsing byte cap the way Facebook does (Facebook's published cutoff is 1MB; earlier guidance cited 60KB). LinkedIn's crawler tolerates reasonable HTML head sizes, but OG tags placed late in <head> after large inline CSS, JSON-LD, and inlined JavaScript can still hit edge cases. Place OG tags as early in <head> as possible.

cause 5 — duplicate or conflicting Open Graph tags

Symptom. Post Inspector picks "a" preview, but not the one you intended. Title or image varies across shares with no apparent cause.

Why it happens. LinkedIn's behavior with duplicates is non-deterministic — sometimes first wins, sometimes last, sometimes the parse falls back to <title>. Three common sources.

  1. Competing WordPress plugins. Yoast + Jetpack + theme-level OG output frequently produces three og:title tags. Disable OG output in two of the three.
  2. Headless CMS rendering at two layers. Next.js with both layout <head> and page <head> writes, Astro with both layout <head> and page injection, Nuxt with useHead overlaying server-rendered tags. Audit the head-merging path.
  3. Server template + client hydration both emitting tags. Server HTML and next/head / vue-meta both write OG tags; you ship two copies.

The Squarespace-specific gotcha. Squarespace's built-in SEO panel writes its own og:image tag. A header code-injection block adding a second og:image tag pointed at a different URL produces two competing tags; LinkedIn picks one nondeterministically. Fix: choose one source — either the SEO panel or code injection, not both — and unset the other.

The Wix-specific gotcha. Wix Editor's SEO settings vs the Velo dev-mode code panel can both write OG tags. Same fix: pick one source-of-truth, disable the other.

Verify. View Source. Cmd-F for og:title. Count should be exactly 1 per property. Repeat for og:image, og:description, og:url.

Resolve. Pick one source-of-truth layer — usually the framework's metadata API. Disable OG output everywhere else. Then validate with Post Inspector — the parsed output shows exactly which of the conflicting tags LinkedIn actually read.

cause 6 — the "first crawl wins" trap (the LinkedIn-specific gotcha)

Symptom. You ran Post Inspector. The parsed output now shows the correct preview. You compose a new LinkedIn post with the URL. The new post still renders the OLD preview.

Why it happens. LinkedIn maintains preview cache at multiple layers. Post Inspector invalidates the lookup cache for the exact URL string submitted, but a downstream cache layer in the post-publishing pipeline — call it the share-API cache — can hold the original preview for longer. This is partly by design (defense against the clickbait swap-after-share pattern named in cause 3) and partly a distributed-cache lag artifact. The architectural fact: Post Inspector and the post composer are not always reading the same cache version at the same moment.

This is the single most under-documented LinkedIn behavior. Almost no SERP competitor names it, and the workaround works for roughly 95% of cases.

The four-step workaround.

  1. Run the URL through Post Inspector. Verify the parsed output is now correct.
  2. Append a query string the URL doesn't currently have: ?ref=linkedin-refresh-2026 or ?utm_source=linkedin-fresh or ?v=2 — anything LinkedIn treats as a new URL string.
  3. Submit the new URL (with query string) to Post Inspector. LinkedIn treats it as a first-time crawl. No cache to override.
  4. Post the URL with the query string in your LinkedIn post. The new preview renders fresh.

Why query strings work. LinkedIn keys its cache by the exact URL string. https://example.com/page and https://example.com/page?ref=linkedin-refresh-2026 are two separate cache entries. The second URL has never been crawled before, so the first-crawl-wins rule writes your current OG tags to the new cache entry as the canonical version for that URL.

The trade-off. The URL in your post now carries a query string. Some destination CMSs strip query strings on canonical pages; most preserve them. If your CMS strips the query string before rendering, the workaround still functions — LinkedIn's crawler sees the query-stringed URL even when the rendered page is identical to the canonical. Worth verifying once for your specific destination if you have analytics tied to query params.

The remaining ~5%. When the workaround above fails — Post Inspector renders correctly, query-stringed submission also renders correctly, but the live post still shows the old preview — you've hit a LinkedIn backend cache state that resists the standard workaround. Two real options:

  1. Wait 24 hours and re-publish. The backend cache layer ages out on a separate, longer TTL.
  2. Publish the link at a genuinely new URL with a 301 redirect from old to new. The new URL gets a clean first crawl; the old URL retains its cached preview indefinitely.

cause 7 — the "low quality content" link suppression

Symptom. Your meta tags are clean. Post Inspector shows a correct preview. You cache-busted with a query string. You published the post. The post got ~30 impressions and stopped.

This is not a tag problem. This is LinkedIn's algorithm-level link suppression, and naming it correctly is most of the fix.

The link-suppression policy, named directly. LinkedIn deprioritizes posts with external links in the feed algorithm. Documented annually by Richard van der Blom's Just Connecting LinkedIn Algorithm Insights — the canonical primary source on LinkedIn algorithm behavior. The 2024 and 2025 reports both confirm: posts with an external link in the body see ~25–40% lower reach on average than text-only posts from the same account. Platform policy, not a bug. Secondary corroboration in Buffer's LinkedIn algorithm coverage and equivalent reporting from Hootsuite and Sprout Social.

The "low quality content" classifier compounds. LinkedIn's content-quality model — referenced indirectly in LinkedIn's content guidelines on link sharing — downgrades posts where the link preview itself is missing, broken, or generic. The signal: if the preview card has no image, a generic title that just repeats the URL, or no description, the link is flagged as "low quality" and distribution is further suppressed. So broken previews compound the baseline link penalty. Fix the preview first; the algorithmic penalty applies on top of a clean preview, but it applies more heavily to broken ones.

Personal profile vs Company Page treatment. Company Pages are distribution-constrained on LinkedIn baseline — the platform's strategy is to monetize Company Page reach via ads. The link penalty applies to Company Pages but is slightly less punitive in relative terms (the baseline reach is already lower, so there's less to lose). Personal profile link posts see the heaviest absolute reach drop.

Premium and Sales Navigator accounts. No observable difference in feed-algorithm link suppression for Premium vs free — the penalty applies equally. Sales Navigator messages (InMail with links) are routed through a different surface and not subject to the feed algorithm at all.

The "link in first comment" hack — sourced. This is the workaround creators cite most often, and almost every article quotes the wrong number for its effectiveness.

  • 2022: Just Connecting reported ~20–30% reach improvement for posts with the link moved to first comment.
  • 2024: Just Connecting reported the gap narrowing to ~10–15%, with diminishing returns as the LinkedIn algorithm caught up to the pattern.
  • 2025: Just Connecting reports ~5–10% lift in best cases. Still slightly positive. No longer transformational.

The 20–30% figure is what AuthoredUp, Taplio, and most secondary articles still quote. It is the 2022 number. The honest 2025 number is ~5–10%, which is real but not the magic bullet it gets sold as.

Other workarounds, listed without endorsement.

  1. Text-only post, link in first comment. ~5–10% lift, 2025-observed.
  2. Native LinkedIn document upload (PDF carousel) instead of external link. Roughly 2–3x reach lift over external-link posts. The most consistently-effective workaround.
  3. LinkedIn Article (long-form on-platform). Roughly 1.5–2x reach over external-link posts. Useful when your content can live natively on LinkedIn.
  4. Linkboo-style short branded links. Do not bypass the penalty — LinkedIn classifies based on link presence, not link domain reputation. They DO get higher click-through when the preview is correct, because the URL itself reads as intentional and trusted versus a raw tracking-parameter URL.

These are observed patterns, not endorsements. The technical preview-rendering pipeline works as documented. The distribution layer is the part LinkedIn shapes to keep users on-platform. Knowing which layer your problem lives in is the entire debugging skill — the same logic that applies to the X (formerly Twitter) link-preview situation, where the algorithm is shadowbanned independently of card rendering.

For solo operators and consultants who depend on LinkedIn-sourced lead-gen, the reach math compounds. The SMB perspective on LinkedIn-sourced lead-gen and coaches using LinkedIn for lead-gen both cover the funnel implications of this penalty at small-team scale.

cause 8 — desktop preview is correct but mobile LinkedIn app shows old preview

Symptom. Post Inspector shows the correct preview. LinkedIn web in your desktop browser shows the correct preview. You open the same post in the LinkedIn iOS or Android app and the old preview is still there.

Why it happens. LinkedIn's mobile apps cache feed cards at multiple layers — in-process, app-data storage, mobile network edge — separate from the central preview cache that Post Inspector invalidates. Post Inspector clears the central cache; the per-device local cache on your phone lags behind.

The fix.

  • Force-quit and reopen the LinkedIn app. iOS: swipe up, remove LinkedIn from the app switcher. Android: Recent Apps + swipe away. Reopen.
  • Clear the LinkedIn app cache (Android). Settings → Apps → LinkedIn → Storage → Clear Cache. iOS does not expose a per-app cache-clear; force-quit is the closest equivalent.
  • Wait 24 hours. The mobile-app local cache TTL ages out passively within 24–48 hours.

The per-device caveat. Your phone's clear-cache fixes the preview only on your phone. Your followers' phones cache independently. Their local caches will refresh on the same 24–48 hour window without any action from them.

If you need the preview correct immediately on an important post. Delete and re-publish with a cache-busted query string (per cause 6). The new post URL is treated as fresh; the post renders the new preview on every device immediately because no local cache exists for the new URL yet.

cause 9 — personal profile vs Company Page preview differences (and the Sales Navigator edge case)

Symptom. Your preview renders correctly when you post from your personal profile but breaks when you post from a Company Page, or the reverse. Or a link shared via Sales Navigator's Share feature renders with subtly different cropping.

Why it happens. Personal profile posts and Company Page posts use the same crawler, the same cache, and the same preview rendering pipeline. The preview data itself is identical. What differs is everything around the preview.

Distribution. Company Pages get less organic reach overall — LinkedIn's strategy is to monetize Company Page distribution via promoted-post advertising. The link suppression from cause 7 applies on top of that lower baseline. The relative penalty is slightly less punitive for Company Pages (because there's less to lose), but absolute reach is lower.

Preview card chrome. Company Page posts surface the Company Page logo as a small badge on the preview card; personal profile posts surface the personal profile photo. This is visual chrome, not a difference in how LinkedIn handles your OG tags.

Sales Navigator Share. When you share a link via Sales Navigator's Share feature (not InMail — Share to your network), the preview rendering can show slightly different cropping behavior on the og:image. Same source data, same crawler, slightly different render layer. Usually irrelevant for content creators; matters for B2B sellers who care about pixel-level consistency between their Sales Nav posts and their feed posts.

Sales Navigator InMail. InMail with a link is routed through a different cache layer than feed posts. The preview rendering is generally the same, but cache invalidation via Post Inspector does NOT propagate to InMail's separate cache. If you send the same URL via InMail to multiple contacts over weeks, the preview can lag a feed-cache refresh. Workaround: append a query string per cause 6, which creates a fresh cache entry that both feed and InMail then share.

LinkedIn Recruiter. Behaves identically to Sales Navigator from a preview-rendering perspective. Same separate cache layer, same workaround.

Showcase Pages. Treated like Company Pages for preview purposes. No additional considerations.

Embedded link in post vs Share-dialog link. A link pasted into a post body unfurls into a preview card on first crawl; a link added via the LinkedIn Share dialog (the "Share an article" widget) routes through a slightly different code path that hits the same cache. Net behavior is functionally identical for the cases that matter — same OG tags, same cache key, same preview output.

If your preview is correct from one surface and broken from another: the cause is almost always cache divergence between surfaces. Post Inspector with a cache-bust query string (per cause 6) creates a fresh entry that all surfaces then read.

the Post Inspector workflow — the four stages, in order

Earlier sections reference this. This is the full procedure.

The Post Inspector lives at https://www.linkedin.com/post-inspector/. It requires a logged-in LinkedIn account — a plain personal account works, no Developer account needed. It is the only published surface that forces a LinkedIn cache refresh before the 7-day TTL ages out naturally.

Stage 1 — Submit URL and read parsed output.

  1. Open https://www.linkedin.com/post-inspector/.
  2. Paste the URL in the input field.
  3. Click Inspect.
  4. LinkedIn returns parsed OG data: image preview, title, description, URL, and any warnings or errors surfaced by the parse.

This is what LinkedIn will render in posts that reference this URL going forward. If you have not previously inspected this URL, this is also the first crawl LinkedIn has done — the parsed data becomes the cached canonical for the URL.

Stage 2 — Identify the gap.

Compare the parsed output to what you want the preview to show. The likely gaps:

  • Image is wrong → cause 4 (image spec violation) or cause 5 (duplicate og:image tags)
  • Title is wrong → cause 1 (missing/malformed og:title) or cause 5 (duplicate tags)
  • Description is wrong → same as title; cause 1 or cause 5
  • No image at all → cause 1 (missing og:image) or cause 2 (image inaccessible to LinkedIn)
  • "Unable to fetch" error → cause 2 (LinkedInBot blocked, server timeout, or HTTPS failure)

Stage 3 — Fix at source.

Make the OG tag change on your published page — update the <head> content, redeploy, or update via your CMS. Verify with View Source on the published URL — the new tags must appear correctly in the server-rendered HTML, not just in Inspect Element's post-JavaScript DOM. Wait ~30 seconds for any CDN to propagate.

Stage 4 — Re-inspect with cache-bust query string.

Re-submit the URL to Post Inspector.

  • If the new preview renders: you're done for new posts. Existing posts retain their original cached preview from when they were first posted — that's a hard LinkedIn constraint per cause 3.
  • If the same old preview returns: you've hit cause 6 (first-crawl-wins). Append a query string (?ref=linkedin-refresh-2026), re-submit, and post the query-stringed URL.

Edge cases that come up in Stage 1.

  • "We're unable to retrieve information for this link" → LinkedInBot couldn't reach your URL at all. Check robots.txt, CDN bot rules, server timeout, SSL chain. Walk cause 2.
  • Post Inspector returns parsed OG data that's stale — wait 30 seconds and re-submit. LinkedIn's backend lag between submit and cache write is real.
  • Same URL inspected twice in a row returns different results — backend cache inconsistency. Submit a third time; the result that appears twice is the cached version.

Per LinkedIn's developer.linkedin.com/share-on-linkedin documentation, there is no public API equivalent of Post Inspector. The closest API surface is the LinkedIn Share API, which has its own preview-validation behavior but is access-restricted and not a substitute for Post Inspector's UI-only cache refresh.

did the fix work? — verify across LinkedIn surfaces

You re-inspected. The preview looks correct in Post Inspector. Confirm it propagated before you publish anything important.

  1. Re-run Post Inspector. Confirm the parsed og:image, og:title, og:description match what you intended. No warnings in the output.
  2. Create a draft LinkedIn post in the composer. Paste the URL. Wait ~5 seconds. The composer's inline preview should match Post Inspector's parsed output. This is the closest live render of how the post will appear in feed.
  3. Don't publish yet. If the composer preview is wrong, you're still hitting cause 6 — cache-bust with a query string per cause 6 and re-run from step 1.
  4. If the composer preview is correct: publish.
  5. Verify on mobile after publish. Open the published post in the LinkedIn iOS or Android app. Force-quit and reopen if you've recently inspected this URL — mobile cache divergence (cause 8) is per-device.
  6. Verify from a second device if possible. Confirms the central cache refreshed for all readers, not just your local one.

If the composer renders correctly but published posts still show the old preview after publish: you're in the residual ~5% of cause 6 where backend cache layers are stuck. Wait 24 hours or republish at a new URL.

when to walk away from the original URL

Some preview problems don't reward more effort. Two scenarios where re-publishing at a new URL is cleaner than continuing to debug.

Cause 6 with a stuck backend cache. When Post Inspector renders correctly, query-stringed submission renders correctly, the composer renders correctly, but the live published post still shows the old preview after multiple attempts — sometimes the cleanest fix is publishing at a genuinely new URL with a 301 redirect from old to new. The new URL gets a fresh crawl; the old URL retains its cached preview indefinitely, which is fine because the redirect bypasses it on read.

Cause 7 link suppression. No technical fix exists. Decisions to make: post link in first comment (~5–10% lift, 2025-observed), upload as native LinkedIn document carousel (~2–3x lift), publish as LinkedIn Article (~1.5–2x lift), or accept the suppression and post anyway. Each is a real trade between platform-policy compliance and reach.

Cause 9 with surface-specific divergence. If you need genuinely different previews from personal profile vs Company Page (different image, different framing), use different URLs per surface — e.g., ?source=company vs ?source=personal. Each URL gets its own cache entry and renders independently. Downside: split analytics across two URLs that point to the same destination.

Accumulated reactions, comments, and reshares stay attached to the original URL forever — LinkedIn does not migrate engagement to a new URL even with a 301 in place. Treat it as a trade, not a default.

the in-app browser side of this problem

Even after your preview is correct, your viewers can hit a related but distinct problem. They tap your perfectly-rendered LinkedIn preview from the LinkedIn mobile app, land in LinkedIn's in-app browser, and the destination treats them as a logged-out stranger.

The mechanism is mechanical. LinkedIn's in-app browser is a WKWebView on iOS and a customized Chromium WebView on Android — the same architectural pattern Instagram, TikTok, Threads, and Messenger use. Cookie jar isolated from Safari and Chrome. The viewer who's logged into Calendly, HubSpot, Stripe, or your own product's dashboard in their default browser is logged out when they land via the LinkedIn webview. The engineering view on webview cookie isolation covers the per-platform isolation specifics in detail.

The conversion stakes on LinkedIn are higher than on most other social platforms because the audience is B2B and the destinations are conversion-gated — booking pages, gated PDFs behind HubSpot forms, Stripe Checkout for course or SaaS purchases, beehiiv or Substack newsletter signups. Calendly's booking widget pulls saved meeting preferences from a cookie; without it, the widget renders the generic flow, slower and less convertible. HubSpot's form pre-fills from a cookie identifying the visitor's company; without it, the form 403s or fires anonymously. Stripe Checkout's Apple Pay button requires access to the device payment keychain that webviews don't have. The pattern is the same across destinations, and the affected surface is "basically every authenticated B2B flow." For per-destination depth: Calendly OAuth flow breakage from the LinkedIn webview, Stripe Checkout's webview rendering issue, identically applicable to LinkedIn, and newsletter subscribe forms inside social-app webviews.

This is the structural problem covered in the in-app browser logged-out problem. The preview can render perfectly and the destination can still log the viewer out. They are two problems with the same shape (per-app cache isolation) but different consequences: one is a vanity issue, the other is the conversion. The full LinkedIn-specific funnel and destination deep-dive lives at /for/linkedin, with the destination-specific math on what gets lost.

If you want to see which in-app browser a given visitor lands in before you debug the consequences, linkboo's in-app browser detector shows you the UA and webview-class of the live request. linkboo wraps the escape flow into a single link — when a LinkedIn follower taps a linkboo URL from the LinkedIn mobile app, the link bounces the destination out to the follower's real browser before the destination loads, so cookies, autofill, saved payment methods, and SSO sessions all survive the transition. Start free on linkboo →.

frequently asked

How long does LinkedIn cache link previews? Approximately 7 days per URL, per LinkedIn's official help-center documentation. Post Inspector forces an immediate refresh for the specific URL submitted; the new preview becomes the cached version for the next ~7 days.

Why does Post Inspector show the correct preview but my new posts still show the old one? First-crawl-wins. LinkedIn's share-API cache layer holds the original preview longer than Post Inspector's lookup cache. Workaround: append a query string (?ref=linkedin-refresh-2026) to the URL, re-submit to Post Inspector, then post the query-stringed URL. LinkedIn treats it as a new URL with no cache to override.

Can I update the preview on a post I've already published? No. LinkedIn does not retroactively update existing posts' preview cards. The cached version at the time of post is permanent for that specific post. To fix it, delete and re-post with the refreshed preview.

What's the right image size for LinkedIn previews — 1200×627 or 1200×630? LinkedIn's official spec is 1200×627 (1.91:1). Facebook's is 1200×630. Three pixels of height differ. In practice 1200×630 works on LinkedIn, but if you're per-platform optimizing, the canonical LinkedIn dimension is 627.

What's the file size limit for og:image on LinkedIn? 5MB hard cap. LinkedIn drops images above 5MB silently. Facebook tolerates up to 8MB; LinkedIn is stricter. Aim for under 1MB for fast, reliable crawl.

Why isn't my WebP image showing on LinkedIn? WebP is technically supported as of 2024+ but feed-card rendering is unreliable on Android specifically as of 2026. Use JPG or PNG for og:image predictability, even if your in-page images are WebP.

Does LinkedIn read twitter:image or og:image? LinkedIn reads og:* tags. It does not read twitter:* tags. If you only emit Twitter Card tags, LinkedIn will fall back to your page <title> and render no image.

Is there a public API for Post Inspector? No. Post Inspector is UI-only and requires authentication via a LinkedIn account. The closest API equivalent is the LinkedIn Share API, which has its own preview-validation behavior but is access-restricted and not a substitute for forcing a cache refresh on an arbitrary URL.

Why does my link post get so few impressions even with a clean preview? LinkedIn's algorithm suppresses external link posts by approximately 25–40% vs text-only or native-content posts from the same account — documented in Just Connecting / Richard van der Blom's annual LinkedIn Algorithm Insights research. Platform policy, not a bug. Workarounds: link in first comment (~5–10% lift in 2025), native PDF carousel (~2–3x lift), LinkedIn Article (~1.5–2x lift).

Does posting from a Company Page change the preview rendering? No — the preview is identical. Distribution is different: Company Pages have lower baseline organic reach, with a slightly less punitive link penalty applied on top.

Will LinkedIn see OG tags injected by JavaScript? Usually no. LinkedInBot executes very limited JavaScript, the behavior is undocumented, and depending on it is unsafe. Server-render the tags (Next.js generateMetadata, Nuxt, SvelteKit, Astro with SSR), static-render at build time, or use a prerender service that detects LinkedInBot/1.0 and serves a pre-rendered snapshot.

Does LinkedIn share its preview cache with WhatsApp, Slack, or Discord? No. Every platform has its own crawler and cache. Facebook + WhatsApp + Messenger + Instagram share a single cache (via facebookexternalhit); LinkedIn (LinkedInBot) is separate; X (Twitterbot) is separate; Slack, Discord, Telegram, and Pinterest each maintain their own. Fixing the LinkedIn preview does not propagate elsewhere — they each need their own validators.

keep reading

guidesFacebook link preview not updating — the 11 causes (and how to diagnose each)Read →guidesThe Facebook Sharing Debugger — every field, every warning, every fixRead →guidesOpen X (formerly Twitter) link card not showing: the honest 2026 fixRead →

Stop losing the click after the tap.

linkboo escapes the in-app browser so your real page loads — fast.

Start for free →