Gids voor de sociale preview-cache: Facebook, WhatsApp, LinkedIn, X, Slack en Discord

Een sociale preview bestaat uit twee delen: de metadata en afbeelding die jouw site serveert, en de kopie die een platform bewaart na het crawlen van jouw pagina. Het corrigeren van het eerste deel wist niet automatisch het tweede.

Dit is de compacte platformkaart voor het diagnosticeren van een verouderde, ontbrekende of bijgesneden productpreview.

Platformvergelijking

Platform Wat je beheert Verversingsrealiteit
Facebook Publieke HTML, og:image, afbeeldings-URL en paginacache Facebook ondersteunt opnieuw scrapen via de Sharing Debugger en het gedocumenteerde scrape-eindpunt. FastOG kan een Facebook-verversing aanvragen wanneer dit is geconfigureerd.
WhatsApp De volgende publieke HTML en afbeeldingsrespons Geen publieke preview-verversings-API. In de cache opgeslagen previews worden beheerd door WhatsApp en kunnen per ontvanger verschillen.
LinkedIn Publieke HTML en afbeeldingsrespons Geen gedocumenteerd programmatisch invalidatie-eindpunt. LinkedIn bepaalt zelf wanneer er opnieuw wordt gecrawld.
X Publieke HTML, twitter:image en fallback Open Graph-tags Geen gedocumenteerd programmatisch invalidatie-eindpunt. X bepaalt zelf wanneer er opnieuw wordt gecrawld.
Slack Publieke HTML en afbeeldingsrespons Slack cached unfurls voor gedeelde URL's; de applicatie kan niet afdwingen dat elk bestaand bericht opnieuw wordt opgebouwd.
Discord Publieke HTML en afbeeldingsrespons Discord cached embeds voor gedeelde URL's; de applicatie kan een bestaande embed niet overal herschrijven.

Platformgedrag en -eindpunten veranderen. Beschouw de tabel als een operationele grens, niet als een belofte over verversingstijden.

Diagnosticeer eerst de oorsprong

Voordat je een platform de schuld geeft, inspecteer je de pagina die een crawler ontvangt:

bash
curl -s https://example.com/product/example | grep -Ei 'og:image|og:title|twitter:image'

Haal vervolgens de afbeeldings-URL op uit de respons:

bash
curl -I "https://cdn.example.com/cover.png"

De pagina moet actuele metadata tonen, de afbeeldings-URL moet openbaar zijn, en de afbeeldingsrespons moet een ondersteund afbeeldingstype retourneren met 200 OK. Als de paginacache oude HTML serveert, kan geen enkel platform de nieuwe cover ontdekken.

Waarom het wijzigen van de image-URL helpt

Sociale platforms cachen de pagina-URL en mogelijk ook de image-URL. Een dynamische cover moet daarom een nieuwe image-URL gebruiken wanneer de productgegevens veranderen. De product-permalink blijft canoniek, terwijl de image-cache-sleutel verandert.

Het toevoegen van ?v=2 aan de product-permalink kan een test er fris uit laten zien, maar het creëert een tweede adres voor hetzelfde product en kan analytics en deelgeschiedenis opsplitsen. Versie de image-URL in plaats daarvan waar mogelijk.

Facebook is de uitzondering

Facebook is het enige platform in deze handleiding waarvoor FastOG een actief her-scrape-pad biedt. Wanneer dit is ingeschakeld, kan een productupdate een verzoek in de wachtrij plaatsen bij Meta's scrape-endpoint voor die product-URL. Het wordt in de wachtrij geplaatst en op best-effort-basis uitgevoerd, zodat een rate limit of een tijdelijke Meta-fout niet voorkomt dat de winkel de juiste metadata serveert.

Dit ververst WhatsApp, LinkedIn, X, Slack of Discord niet. Beschrijf een Facebook-her-scrape niet als een universele social-cache-purge.

Een praktische volgorde van handelingen

  1. Haal de live pagina op en bevestig de huidige tags.
  2. Leeg de page cache van de site of de CDN als de tags verouderd zijn.
  3. Bevestig dat de afbeeldings-URL openbaar is en een afbeelding retourneert.
  4. Wijzig de afbeeldings-URL wanneer de afbeeldingsbytes zijn veranderd.
  5. Gebruik voor Facebook de debugger van Facebook of het geconfigureerde re-scrape pad.
  6. Wacht voor andere platforms op een nieuwe crawl of deel een URL die nog niet in de cache zit. Beloof geen exacte vertraging.

De Gratis OG Afbeeldingstester kan een product-URL ophalen en de voor crawlers zichtbare metadata tonen naast een gegenereerde cover. Het is nuttig om een probleem aan de winkelzijde te onderscheiden van een cache aan de platformzijde.

FAQ

Kan één plugin elke social preview vernieuwen?

Nee. Een plugin kan de HTML en de afbeeldings-URL bepalen die de site serveert. Elk platform beheert zijn eigen crawler en cache.

Waarom ziet de preview er op Facebook correct uit, maar op WhatsApp verouderd?

De platforms onderhouden afzonderlijke caches. Een her-scrape door Facebook wijzigt alleen de kopie van Facebook; WhatsApp behoudt zijn eigen ontvanger-specifieke preview.

Moet ik de product-URL na elke prijswijziging aanpassen?

Meestal niet. Houd de canonieke product-URL stabiel en wijzig de gegenereerde afbeeldings-URL wanneer de coverinhoud verandert. Het wijzigen van de pagina-URL is een botte cache-omzeiling met SEO- en analyserisico's.

Garandeert een nieuwe afbeeldings-URL een onmiddellijke WhatsApp-update?

Nee. Het garandeert dat de volgende ophaalactie van die afbeeldings-URL nieuwe bytes kan ontvangen. Het dwingt WhatsApp niet om de pagina op te halen of een preview die al in de app van een ontvanger is opgeslagen, te vervangen.

Probeer het gratis — geen aanmelding vereist

Bekijk en test dynamische OG-afbeeldingen in seconden.

Open de gratis OG-afbeeldingstester

From Us

A BeCaSimulations site