agoda.com

com into Slack iMessage LinkedIn Twitter Facebook or WhatsApp the platform's scraper races to fetch the page parse a small set of specific meta tags and assemble the rich preview card displayed beneath the message.

If those tags are missing or misconfigured the preview degrades to a hostname and a tiny favicon — and research consistently shows that a textual fallback card earns roughly half the click-through rate of a properly tagged visual card. com's homepage — without it scrapers fall back to the element which is often too long and formatted for search rather than sharing.

No og:description is set so every social share shows the platform's best guess at a description — usually the first block of body text which is rarely click-optimised. com — this is the most expensive missing tag because every social share will render as a textual card with no visual hook. No twitter:card is set so X will guess the card type — usually defaulting to the basic summary layout with a small thumbnail.

We also check for the standard fallbacks — and — that platforms like Slack and iMessage reach for when og:* tags are absent.

The Open Graph protocol was introduced by Facebook in 2010 and has since become the de-facto schema for social link previews across every major platform. Each scraper has its own quirks that trip up even experienced developers.

Twitter (now X) reads og:image but prefers a dedicated twitter:image tag when present and the card layout depends on twitter:card — summary_large_image gives the full-width hero image familiar from news shares while summary renders a compact square thumbnail. Using summary_large_image for content-heavy pages and summary for utility or app pages is the correct division.

LinkedIn caches og:image aggressively sometimes for up to seven days meaning a fix to the image URL won't appear in new shares until you force a re-scrape using LinkedIn's Post Inspector — a step many teams skip and then assume the fix failed.

Slack and Discord pre-fetch links eagerly and have tight constraints: they refuse images larger than 2 MB reject URLs that don't return a 200 over HTTPS and can't render WebP in all clients — JPEG or PNG at under 1 MB is the safe choice.

WhatsApp and iMessage are stricter than web platforms: they use the og:image as-is and don't fall back to body images so a missing or broken og:image means a completely text-only preview on mobile where sharing behaviour is highest.

The canonical sweet spot for og:image in 2026 is 1200×630 pixels JPEG or PNG under 1 MB with explicit og:image:width and og:image:height tags present so scrapers can lay out the card without downloading the full image first. com is currently missing an og:image — the single most impactful tag to add.

Keep the most important visual content within the central 1080×566 pixels because Twitter crops the card on mobile and anything near the edges may be hidden.

com covers eight specific tags and keeps them synchronised with the page's on-page metadata. og:title should be 50–70 characters — close to the page but written for sharing rather than search ranking; short punchy phrasing outperforms SEO-keyword-heavy titles in click-through on social.

og:description should be 100–160 characters and answer the why should I click this question not rephrase the title — it's the copy that appears beneath the card image on most platforms. og:image must be an absolute HTTPS URL pointing to a 1200×630 JPEG or PNG accompanied by og:image:width and og:image:height so scrapers can allocate space before fetching the file.

og:type should match the actual for the homepage and landing pages article for blog posts and news product for e-commerce items — each type unlocks different structured preview behaviours on platforms that support them. io since most scrapers display it as a secondary label beneath the preview title.

twitter:card set to summary_large_image for content pages and supplemented by twitter:site (your @handle) lets X attribute shares correctly and activates analytics in X's dashboard. Re-run this report after every redesign template change or CMS migration — og:image is the tag most commonly broken silently and the failure only surfaces when someone actually shares the page.

Getting the tags right is only half the job — the other half is forcing each platform to re-read them because every major scraper maintains an aggressive cache that will keep serving a stale or broken preview long after you've fixed the underlying tags. com: ship the tag change then re-scrape on each platform that matters using its own first-party debugger.

Facebook's Sharing Debugger and X's Card Validator each fetch the page fresh and immediately bust their own cache. LinkedIn's Post Inspector does the same but requires you to wait a few seconds and then click the re-scrape button explicitly. Slack re-fetches when its cached entry expires; Discord re-fetches immediately if you paste a link in a different channel.

Until you complete that re-scrape pass on each platform your test shares will keep showing the old preview and you may falsely conclude the fix failed.

The most common silent regressions to watch for: an og:image URL that returns a 404 after a CDN path change or an asset rename during a redesign; an image served behind cookie-based authentication that the scraper sees as a 403; a relative og:image path that a browser resolves correctly but a scraper which doesn't have a base URL context cannot; and a CDN that conditionally serves WebP based on the Accept header which some scraper user-agents don't send producing a broken image on platforms that don't support WebP.

com — a vanished og:image caught the day it breaks costs minutes to fix; one that goes unnoticed for a week means hundreds of shares rendering as textual previews with no visual hook.