Learning Hub — Beginner’s Guide
⭐ Beginner — No coding experience needed

What you will learn in this guide

1 How previews are generated

When you paste a URL into Facebook, LinkedIn, Twitter, Discord or Slack, each platform fetches your page once, reads the meta tags, and stores a cached preview. Every share after that reuses the cached version until the platform decides to refetch — and none of the platforms publish how long that is, so treat any specific figure you see quoted as folklore rather than fact.

Why this matters:If your OG tags are wrong when someone first shares the URL, the bad preview is what gets cached — and it is then what everyone else sees, potentially for a long time, because the platform is no longer looking at your page. Fix before publishing, not after.

2 Test before publishing

  1. 1Run the Social Preview toolOpen content-tools.html#social-preview and paste your URL. See exact previews for Facebook, LinkedIn, Twitter, Discord, Slack and iMessage.
  2. 2Check each platform separatelyEach platform uses slightly different aspect ratios and text lengths. A preview that looks fine on Facebook may be cropped weird on Twitter.
  3. 3Use platform-specific debuggersFacebook Sharing Debugger, LinkedIn Post Inspector, Twitter Card Validator. Each forces a fresh fetch of your URL and shows what their platform sees.
  4. 4Clear cache after fixingIf you find a problem, fix it, then re-run each debugger to clear the cache before promoting the URL.

3 Common preview problems

ProblemLikely causeFix
Tiny logo instead of imageMissing og:imageAdd og:image with absolute URL
Wrong titleog:title missing; using page instead</td><td>Add explicit og:title</td></tr><tr><td>Image cropped weirdly</td><td>Aspect ratio not 1.91:1 (1200x630)</td><td>Resize to 1200x630</td></tr><tr><td>Old image still shows after edit</td><td>Platform cache (30 days)</td><td>Use platform debugger to refresh</td></tr><tr><td>Image not loading</td><td>Relative URL or blocked by referrer policy</td><td>Use absolute URL; allow social bot user agents</td></tr></tbody></table> </div> <div class="tutorial-section"> <h2><span class="section-num">4</span> Force a cache refresh</h2> <ol class="step-list"><li class="step-item"><span class="step-num">1</span><span class="step-content"><span class="step-title">Facebook</span><span class="step-body">Open developers.facebook.com/tools/debug. Paste URL. Click "Scrape Again". Updated immediately on Facebook.</span></span></li><li class="step-item"><span class="step-num">2</span><span class="step-content"><span class="step-title">LinkedIn</span><span class="step-body">Open linkedin.com/post-inspector. Paste URL. The fetch refreshes LinkedIn's cache.</span></span></li><li class="step-item"><span class="step-num">3</span><span class="step-content"><span class="step-title">Twitter</span><span class="step-body">Twitter's validator was deprecated; current workaround is post a tweet with a query parameter (e.g., ?v=2) which forces a fresh fetch.</span></span></li><li class="step-item"><span class="step-num">4</span><span class="step-content"><span class="step-title">Discord/Slack</span><span class="step-body">These respect OG tags but cache aggressively. Adding a query parameter usually forces a re-fetch.</span></span></li></ol><div class="tip-box"><strong>Cache TTLs</strong>None of these platforms publishes its cache duration, and the figures that circulate are community guesses rather than documented behaviour. Assume the cache is long, assume you cannot wait it out, and use the debuggers to force a refresh instead.</div> </div> <div class="tutorial-section"> <h2><span class="section-num">5</span> The cache is the whole problem</h2> <p>Almost every "my OG tags do not work" report is a cache problem, not a tag problem. The tags were fixed. The platform simply is not looking at them.</p> <p>These platforms fetch your page <em>once</em>, when a link is first shared, and then keep what they found. They do not come back to check. So the moment somebody shares your URL, whatever your page said at that instant becomes the preview everybody else sees — and editing the markup afterwards changes nothing, because the platform has stopped reading your page.</p> <p>How long does that last? Nobody outside those companies knows. None of them publishes a cache duration, and the specific figures that circulate online are community guesses that change without announcement. The practical consequence is identical whatever the true number is: <strong>assume the cache is long, assume you cannot wait it out, and force a refresh.</strong></p> <div class="tip-box"><strong>Which is why the order of operations matters more than anything else in this guide.</strong> Fix the tags first, run the debugger to force a re-fetch, <em>then</em> promote the URL. Do it the other way round and the bad preview is already in circulation, being served from a cache you no longer control.</div> </div> <div class="tutorial-section"> <h2><span class="section-num">6</span> What OG tags do not do</h2> <p>It is worth saying directly, because a great deal of advice implies otherwise: Open Graph tags do not help your Google rankings.</p> <p>Google does not use og:title or og:description as ranking signals. A page with immaculate OG markup will rank exactly where the same page without it would have ranked. These tags exist to control how your link appears on platforms that are not search engines, and that is the whole of their function.</p> <p>That is not an argument against them. It is an argument for using them for the right reason. A link shared into a Slack channel or a LinkedIn feed with a clear image and a description written for a human is a link people click. A link showing a cropped logo and the first sentence of your cookie banner is a link people scroll past. The benefit is in the click-through on shares — genuine, measurable, and not a ranking benefit.</p> <p>The related overclaim to avoid: og:description is not a place for keywords. Nothing reads it except the platform rendering the preview, and the person who sees that preview is deciding whether to click. Write it for them.</p> </div> <div class="tutorial-section"> <h2><span class="section-num">7</span> The image is doing all the work</h2> <p>In a feed or a chat window the image occupies most of the preview's visual footprint, which means it is doing nearly all of the persuading. If you get one tag right, get og:image right.</p> <ol class="step-list"> <li class="step-item"><span class="step-num">1</span><span class="step-content"><span class="step-title">Absolute URL, over HTTPS</span><span class="step-body">A relative path is the single most common cause of a preview with no image at all. The platform is fetching from the outside; it cannot resolve /images/hero.png against a context it does not have.</span></span></li> <li class="step-item"><span class="step-num">2</span><span class="step-content"><span class="step-title">Check your server is not blocking the fetcher</span><span class="step-body">Bot-mitigation and hotlink-protection rules routinely refuse unfamiliar user-agents, including the platform crawlers. The debugger will say it could not fetch the image; your access log will confirm why.</span></span></li> <li class="step-item"><span class="step-num">3</span><span class="step-content"><span class="step-title">Keep content away from the edges</span><span class="step-body">Platforms crop to different ratios. Text near the left or right edge loses its first or last words somewhere — and you will not see it happen, because it happens on somebody else's phone.</span></span></li> <li class="step-item"><span class="step-num">4</span><span class="step-content"><span class="step-title">Make any text large</span><span class="step-body">Previews are often rendered far smaller than the source image. Text sized for a desktop screenshot is unreadable by the time it reaches a feed.</span></span></li> <li class="step-item"><span class="step-num">5</span><span class="step-content"><span class="step-title">Give important pages their own image</span><span class="step-body">A single company logo used site-wide produces a preview that is technically valid and says nothing about the page. If a page is worth sharing, it is worth an image that shows what it is about.</span></span></li> </ol> </div> <div class="tutorial-section"> <h2><span class="section-num">8</span> Where to spend the effort, and the test that ends the argument</h2> <p>You do not need bespoke tags on every page, and a generic site-wide rollout is a poor use of an afternoon. The pages that actually get shared are a small and predictable set: the homepage, the pricing or main product pages, and the handful of articles people link to.</p> <p>Do those properly — a real image, a title that reads well out of context, a description written for somebody scrolling a feed. Then set a sensible fallback for everything else so that nothing ever produces a genuinely broken preview.</p> <p>And set og:url to the canonical URL, which is the detail nobody thinks about. Platforms use it to decide whether two shares refer to the same link, so it is what consolidates share counts. If it reflects whatever tracking-parameter-laden variant the sharer happened to copy, every variant is counted as a different link.</p> <p>Then run the only test that answers the question: share the link into a private channel or a draft post, and look at what appears. Everything a validator tells you is about your markup. Only the preview tells you about the result — and it is your last chance to catch a bad one before it is cached and shared by everybody.</p> </div> <div class="tutorial-section"> <h2><span class="section-num">9</span> Frequently asked questions</h2> <div class="info-box"><strong>Why did my preview not update after I fixed the tags?</strong><p>Because the platform cached it. Facebook, LinkedIn, Slack and the rest fetch your page once, when a link is first shared, and then keep what they found — they do not come back to check. Editing your tags afterwards changes nothing about a preview that has already been stored, because the platform is no longer looking at your page. Run the URL through the platform's own debugger to force a re-fetch. This single step accounts for the large majority of 'my OG tags do not work' reports.</p></div> <div class="info-box"><strong>How long do the platforms cache a preview?</strong><p>Nobody outside those companies knows, and none of them publishes it. The specific durations you will see quoted around the web are community folklore, not documented behaviour, and they change without announcement. The practical consequence is the same whatever the true number is: assume the cache is long, assume you cannot wait it out, and force a refresh with the debugger rather than hoping.</p></div> <div class="info-box"><strong>Do Open Graph tags help my SEO?</strong><p>No. Google does not use og:title or og:description as ranking signals, and adding them will not move a page in the results. What they control is how your link appears when somebody shares it — on Facebook, LinkedIn, Slack, Discord, WhatsApp and most messaging apps. That matters commercially because a share with a broken preview gets fewer clicks than a share with a good one. The benefit is real; it is a sharing benefit rather than a ranking one, and it is worth being clear which is which.</p></div> <div class="info-box"><strong>Why does my image not appear at all?</strong><p>The most common cause by far is a relative URL in og:image. The platform is fetching your page from the outside; it cannot resolve /images/hero.png against a context it does not have. Use an absolute URL over HTTPS. The second most common cause is your own server blocking the platform's fetcher — a bot-mitigation rule or a hotlink-protection rule that refuses unfamiliar user-agents. The debugger will usually tell you it could not fetch the image, and your access log will confirm it.</p></div> <div class="info-box"><strong>What image size actually works everywhere?</strong><p>1200 by 630 pixels is the safe default: it matches the roughly 1.91:1 ratio the major platforms expect and degrades gracefully elsewhere. Keep important content away from the edges, because different platforms crop differently and your headline will lose its first or last words on somebody's phone. And make any text in the image large — previews are frequently displayed at a fraction of the source dimensions, so text sized for a desktop screenshot is illegible by the time anybody sees it.</p></div> <div class="info-box"><strong>Do I need Twitter Card tags as well as Open Graph?</strong><p>Not strictly. X falls back to Open Graph when the twitter:* equivalents are absent, so correct OG tags will produce a reasonable preview there with no extra work. The reason to add them is control: twitter:card lets you choose between a small thumbnail and a large image card, and the large card is substantially more visible in a feed. If you add them, add all of them — declaring a large image card without supplying twitter:image produces a worse result than saying nothing at all.</p></div> <div class="info-box"><strong>What is the one test worth doing before I publish?</strong><p>Share the link into a private Slack channel or a draft post, and look at what appears. That is the only test that shows you what your visitors will actually see. Everything a validator tells you is about your markup; only the preview tells you about the result — and the gap between the two is where cropped headlines, stock-photo logos and missing images all live. It costs a minute, and it is the last chance to catch a bad preview before it gets cached and shared by everybody.</p></div> </div> <div class="author-bio" itemscope itemtype="https://schema.org/Person"> <div class="author-avatar" aria-hidden="true">👤</div> <div class="author-info"> <div class="author-label">Written by</div> <div class="author-name" itemprop="name">John</div> <div class="author-title" itemprop="jobTitle">Founder, aiwebpageseo</div> <p class="author-bio-text" itemprop="description">Social previews are tiny details that hugely affect click-through rates from social media. A 5-minute preview audit before publishing is one of the highest-impact pre-launch checks you can do.</p> <div class="author-links"> <a href="https://aiwebpageseo.com" class="author-link" itemprop="url" target="_blank" rel="noopener">🔗 aiwebpageseo.com</a> <a href="/content-tools.html#social-preview" class="author-link" target="_blank" rel="noopener">🔍 Try the tool →</a> </div> </div> </div> <div class="related-wrap"> <div class="related-title">Related guides</div> <div class="related-grid"> <a href="/aipageseo-demo-pages/novice-tutorial-og-generator.html" class="related-card"><div class="related-card-type">Beginner Guide</div><div class="related-card-title">Open Graph Tags</div></a><a href="/aipageseo-demo-pages/novice-tutorial-meta-analyzer.html" class="related-card"><div class="related-card-type">Beginner Guide</div><div class="related-card-title">Meta Tags</div></a><a href="/aipageseo-demo-pages/novice-tutorial-serp-preview.html" class="related-card"><div class="related-card-type">Beginner Guide</div><div class="related-card-title">SERP Preview</div></a> </div> </div> <div class="page-footer"> <p>Part of the <a href="/seo-audit-platform.html">aiwebpageseo Suite</a> · <a href="/pricing.html">Pricing</a> · <a href="/seo-auth/dashboard.html">Dashboard</a></p> </div> </div> <script> window.addEventListener('scroll', function(){ var doc = document.documentElement; var scrolled = doc.scrollTop; var total = doc.scrollHeight - doc.clientHeight; var pct = total > 0 ? (scrolled / total) * 100 : 0; document.getElementById('progress-fill').style.width = pct + '%'; }); </script> <div style="max-width:1100px;margin:0 auto;padding:16px 24px;border-top:1px solid #dbeafe;font-family:'Outfit',sans-serif;"> <h3 style="font-size:11px;font-weight:700;letter-spacing:.6px;text-transform:uppercase;color:#94a3b8;margin:0 0 8px;">About aiwebpageseo</h3> <p style="font-size:13px;line-height:1.7;color:#94a3b8;margin:0;max-width:880px;">aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.</p> </div> </body> </html>