Open Graph-afbeeldingsformaat: één bestand voor elk platform

Eén afbeelding van 1200 bij 630 pixels, in PNG of JPEG, onder ongeveer 1 MB, met de belangrijke inhoud binnen het middelste vlak van 1080 bij 600. Dat bestand rendert correct op Facebook, LinkedIn, X, Slack, Discord, WhatsApp en iMessage, en dat is het complete antwoord op de vraag naar het Open Graph-afbeeldingsformaat voor bijna elke site.

De afmetingen zijn het makkelijke deel. Meestal is dat ook niet wat er misgaat. Wat er misgaat, is tekst die te dicht tegen een rand staat die één platform bijsnijdt, een afbeelding die nooit bijwerkt omdat een crawler de oude versie maanden geleden heeft gecacht, of een kaart die zonder afbeelding rendert omdat het bestand 4 MB was op een trage origin. De vraag naar het OG-afbeeldingsformaat is eigenlijk drie vragen, en maar één ervan gaat over pixels. Deze gids behandelt de specificatie, de veilige zone, het cachegedrag dat mensen laat denken dat hun tags fout zijn, en hoe previews worden opgelost wanneer wat er gedeeld wordt een korte link is. Is jouw preview volledig afwezig in plaats van slecht bijgesneden, dan is linkpreview verschijnt niet de diagnosegids.

Het formaat, en waarom het dit formaat is

De verhouding 1.91:1 komt van Facebook's linkkaart, en die is blijven hangen omdat iedereen verder een compatibele lay-out overnam in plaats van zijn eigen formaat te bedenken. Het Open Graph-protocol zelf zegt helemaal niets over pixels; het definieert og:image als een URL en laat het renderen over aan de consument, en precies daarom is er een de-facto standaard ontstaan rond één handig formaat.

Facebook's eigen richtlijnen voor het delen van afbeeldingen leggen het minimum op 200 bij 200 en raden het grotere bestand aan voor schermen met hoge resolutie, en X documenteert de kaartmarkup apart, wat de enige plek is waar je een platformspecifieke tag nodig hebt in plaats van een platformspecifiek bestand.

De veilige zone die niemand noemt

Een kaart wordt zelden getoond in de verhouding waarin je hem hebt ontworpen. Chatapps snijden bij richting vierkant voor de thumbnail, sommige feeds scheren de zijkanten af bij smalle viewports, en een afgeronde hoek vreet de laatste paar pixels van een hoeklogo op.

Houd alles dat moet overleven binnen het middelste vlak van 1080 bij 600, gecentreerd, en behandel de buitenste rand als decoratie die je kunt missen. In de praktijk betekent dat: de kop staat centraal-links in plaats van strak tegen de rand, het logo leeft binnen de marge in plaats van in de hoek, en er is geen dunne rand, omdat een rand het ene ontwerpelement is dat er meteen kapot uitziet zodra het wordt bijgesneden.

Contrast is ook belangrijker dan het lijkt. Kaarten renderen in de ene client op wit en in de andere op bijna-zwart, dus een afbeelding die voor scheiding leunt op de omringende achtergrond, verliest zijn randen in de helft van de gevallen.

De tags rond de afbeelding

Vier tags doen het werk. Twee daarvan zijn de tags die mensen overslaan.

<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
  property="og:image:alt"
  content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />

De URL moet absoluut zijn, inclusief scheme en host, omdat de crawler de tag zonder paginacontext leest en geen relatief pad kan oplossen. Breedte en hoogte laten het platform de juiste ruimte reserveren voordat het bestand binnenkomt, en dat is het verschil tussen een kaart die meteen verschijnt en een die naderhand herschikt. En og:image:alt is de toegankelijkheidstag die niets kost en bijna overal ontbreekt.

Waarom je nieuwe afbeelding niet verschijnt

Dit is degene die supporttickets oplevert. Je hebt de afbeelding gerepareerd, je kunt het nieuwe bestand op zijn URL zien, en de kaart toont nog steeds het ontwerp van vorig kwartaal.

Social crawlers cachen agressief, en ze doen daar niet subtiel over. Zodra een URL is gescrapt, is de opgeslagen versie wat wordt gerenderd bij volgende shares, soms wekenlang, en niets aan het bewerken van je HTML vertelt hen om opnieuw te kijken. Drie manieren om eruit te komen, in de volgorde waarin ik ze zou proberen:

• Forceer een nieuwe scrape met de eigen tool van het platform: zowel Facebook's Sharing Debugger als LinkedIn's Post Inspector halen op aanvraag opnieuw op.
• Publiceer de afbeelding onder een nieuwe bestandsnaam, wat een andere URL is en dus helemaal geen cache-entry heeft. Dit is de betrouwbare optie.
• Verander de gedeelde URL zelf, wat triviaal eenvoudig is wanneer wat je deelt een korte link is die jij beheert in plaats van een permanent pagina-adres.

Voordat je iets publiceert, laat de Open Graph-checker je de kaart precies zien zoals een crawler die zou bouwen, wat tien seconden kost en de ongemakkelijke reshare bespaart.

Previews wanneer je een korte link deelt

Een korte link heeft geen eigen Open Graph-tags en heeft die ook niet nodig. De crawler volgt de redirect, landt op de bestemming, en bouwt de kaart op basis van de tags daar, wat betekent dat een verkorte URL de preview erft van wat de doelpagina heeft. Als de kaart fout is, zijn de tags op de bestemming fout.

Twee dingen hangen wel af van de linklaag. De redirect moet volgbaar zijn voor een crawler, wat het normale geval is bij een server-side sprong, maar niet bij een JavaScript-redirect, weer een reden om de keten kort en server-side te houden. En omdat de preview bij de bestemming hoort, verandert het verleggen van een korte link ook de preview ervan, wat een stilletjes nuttige eigenschap is wanneer een campagnepagina wordt vervangen nadat de link al is gedeeld.

Wil je de link, de kaart en de klikdata op één plek, start dan een workspace op je eigen domein en controleer de kaart met de tool vóór het versturen in plaats van erna.

Een checklist die het bewaren waard is

• 1200 bij 630, PNG of JPEG, onder 1 MB, absolute HTTPS-URL. Dat is de hele beslissing over het OG-afbeeldingsformaat.
• Niets belangrijks buiten het middelste vlak van 1080 bij 600, geen dunne randen.
• og:image:width, og:image:height en og:image:alt aanwezig.
• twitter:card ingesteld op summary_large_image als je de grote kaart op X wilt.
• Nieuwe afbeelding, nieuwe bestandsnaam, en dan opnieuw scrapen voordat je iets aankondigt.

Krijg die vijf punten één keer goed, zet ze als sjabloon in de head van je pagina, en Open Graph-afbeeldingen stoppen een ding te zijn waar je over nadenkt. En dat is precies de juiste hoeveelheid aandacht om eraan te geven.

Lees de cornerstone-serie

Dit artikel valt onder de tutorials-cluster. Voor previews die helemaal mislukken in plaats van slecht worden bijgesneden, is linkpreview verschijnt niet de platform-per-platform-oplossing, en hoe je een klikbare link maakt behandelt de laag eronder.

Gerelateerd op de blog

• Linkpreview verschijnt niet? Oorzaken en hoe je het oplost
• Een link verkorten voor X (Twitter): wat t.co ermee doet
• Hoe je social-media-links bijhoudt: klikken per kanaal
• Wat is een merkgebonden link, en waarom converteert die beter
• Hoe je een URL doorverwijst: zes manieren, en wanneer welke de juiste is
• Custom domains voor korte links: DNS, TLS en de edge