Dynamische Open Graph Bilder erklärt

Dynamische Open-Graph-Bilder werden bei der Anfrage erzeugt, statt als statische Dateien zu liegen. Jede Seite kann eine eigene Vorschau mit passendem Titel, Autor oder Produktnamen im Bild liefern - ohne hunderte JPGs manuell zu exportieren.

Betreibst du Blog, Docs oder SaaS mit vielen URLs, sind dynamische OG-Bilder oft die einzige skalierbare Option.

Statisch vs. dynamisch

Beide nutzen dasselbe Meta-Tag:

<meta property="og:image" content="https://example.com/api/og?slug=hello-world">

Der Unterschied: Zeigt die URL auf eine Datei im Storage oder auf eine Route, die das Bild pro Request baut (oft gecacht)?

Wie dynamische Generierung funktioniert

1. Du definierst ein Template (Layout, Fonts, Farben, Logo).
2. Die App übergibt Seitendaten (Titel, Kategorie, Preis, Avatar).
3. Eine Server-Route rendert ein 1200 × 630 px Bild.
4. Die Response wird am CDN oder Edge gecacht.
5. Social Crawler holen die URL wie jedes andere og:image.

Crawler führen kein JavaScript aus. Das Bild muss eine direkte URL sein, die Content-Type: image/png oder image/jpeg mit HTTP 200 liefert.

Next.js App Router

Next.js 13+ unterstützt dynamische OG-Bilder via ImageResponse aus next/og (basiert auf Satori).

File-basierte Route (gängiges Pattern)

Erstelle app/opengraph-image.tsx neben Page oder Layout:

import { ImageResponse } from "next/og"
export const runtime = "edge"
export const alt = "Seiten-Vorschau"
export const size = { width: 1200, height: 630 }
export const contentType = "image/png"
export default async function Image() {
  return new ImageResponse(
    (
      <div
        style={{
          width: "100%",
          height: "100%",
          display: "flex",
          alignItems: "center",
          justifyContent: "center",
          background: "#111",
          color: "#fff",
          fontSize: 64,
          fontWeight: 700,
        }}
      >
        Dein Seitentitel
      </div>
    ),
    { ...size }
  )
}

Next.js verdrahtet das automatisch mit den Open-Graph-Metadaten der Seite. Jede Route kann eigene opengraph-image.tsx haben.

Dynamische Route mit Params

Für [slug]-Pages den Slug in der Image-Route lesen, Post-Titel aus dem CMS holen und im Template rendern.

Metadata-API-Alternative

Du kannst openGraph.images auch in generateMetadata setzen:

export async function generateMetadata({ params }) {
  const post = await getPost(params.slug)
  return {
    openGraph: {
      images: [`https://example.com/api/og/${params.slug}`],
    },
  }
}

Zeige auf eine dedizierte API-Route, wenn du Query-Params oder geteilte Logik brauchst.

Andere Stacks

Vercel OG / @vercel/og

Dasselbe Satori-Rendering, läuft in Edge Functions auf Vercel und kompatiblen Hosts. Gut für Non-Next-Projekte.

Puppeteer oder Playwright

Echte HTML-Seite in Headless Chrome rendern und screenshotten. Flexibel, aber langsamer als Satori. Aggressiv cachen.

Cloudinary / Imgix Overlays

Basis-Template im CDN, Text-Overlays per URL-Parameter. Keine Code-Route nötig, weniger Typo-Kontrolle.

PHP, Ruby, Python

GD, Imagick oder Pillow für Text auf Template serverseitig. Älteres Pattern, zuverlässig in WordPress-Plugins und Rails.

Caching ist Pflicht

Dynamisch heißt nicht „bei jedem Request neu rendern". Ohne Cache-Header hammer dein Origin bei jedem Share.

Setze lange Cache-Control auf der Image-Response:

Cache-Control: public, max-age=31536000, immutable

Invalidiere durch URL-Änderung bei Content-Updates (/api/og/post-slug?v=2). Siehe Open Graph Cache Busting.

Design-Grenzen bei generierten Bildern

Satori (Next.js) unterstützt eine Teilmenge von CSS Flexbox. Nicht jeder Figma-Effekt übersetzt sich.

Was gut funktioniert

• Flexbox-Layout
• System-Fonts und eingebettete Custom Fonts (TTF/OTF)
• Vollflächen, Borders, Border-Radius
• Inline-Bilder (Logo als ArrayBuffer laden)

Was bricht

• Komplexes CSS Grid
• Box-Shadows (limitiert)
• Web-Fonts ohne explizites Laden
• Animationen (irrelevant für statisches PNG)

Templates simpel halten: Hintergrundfarbe, Logo, ein bis zwei Textzeilen. Passend zu den Design-Tipps für lesbare Headlines bei 1200 × 630.

Dynamische OG-Bilder testen

Dynamische Routen scheitern in Produktion leise, wenn Fonts nicht laden oder die Edge Runtime wirft.

1. og:image-URL direkt im Browser öffnen. Du solltest das Bild sehen, kein HTML oder JSON.
2. Response-Header prüfen: 200, korrekter Content-Type.
3. Seiten-URL mit OpenGraph Check scannen, ob Crawler die richtige Image-URL bekommen.
4. Nach Template-Änderungen im Facebook Sharing Debugger re-scrapen.

Typischer Fehler: Image-Route braucht Auth oder blockt Bots. Crawler müssen ohne Cookies drankommen.

Wann statische Bilder noch besser sind

• Einmalige Marketing-Landingpages mit Hand-Artwork
• Kampagnen mit Design-Review in Photoshop
• Sites ohne Server-Side Rendering

Für eine 5-Seiten-Brochure: PNG exportieren, fertig. Für 500 Blog-Posts: dynamisch.

No-Code-Option: OG-Bild-Generator

Du brauchst keinen Code für ein solides Template. Der kostenlose OG-Bild-Generator von OpenGraph Check lässt dich ein 1200 × 630 Bild im Browser designen, Text und Hintergrund setzen und die Datei downloaden. Upload ans CDN, Referenz in og:image.

Generator für statische Seiten. Dynamische Generierung, wenn Titel pro URL wechseln.

Häufige Fehler

Nur Client-side Canvas-Export

Bild im Browser mit <canvas> erzeugen hilft Crawlern nicht, außer du lädst das Ergebnis hoch und setzt og:image serverseitig auf die gehostete URL.

Relative og:image-Pfade

Dynamische Routen brauchen trotzdem absolute URLs:

<meta property="og:image" content="https://example.com/api/og?title=Hello">

Twitter Card vergessen

Setze twitter:image auf dieselbe dynamische URL bei Large Image Cards. Siehe Open Graph vs. Twitter Card.

Kein Fallback bei Generierungsfehler

Liefere ein Default-Brand-Bild, wenn CMS-Lookup scheitert. Generisches Fallback schlägt 500-Fehler und leere Vorschau.

FAQ

Was ist ein dynamisches Open-Graph-Bild?

Eine og:image-URL, die pro Seite bei der Anfrage ein einzigartiges Bild aus einem Server-Template erzeugt, statt einer statischen Datei für die ganze Site.

Unterstützt Next.js dynamische OG-Bilder?

Ja. Nutze opengraph-image.tsx mit ImageResponse aus next/og, oder eine API-Route, die PNG/JPEG-Bytes zurückgibt.

Sind dynamische OG-Bilder langsamer für Crawler?

Können sein, ohne Caching. Mit CDN-Cache und Edge-Rendering entsprechen Response-Zeiten statischen Files nach dem ersten Request.

Dynamische OG-Bilder auf WordPress?

Ja, via Plugins mit serverseitiger Bildgenerierung oder Custom PHP mit Imagick. Headless WordPress oft mit Next.js-Frontend für OG-Generierung.

Funktionieren dynamische Bilder auf LinkedIn und Facebook?

Ja, wenn die URL öffentlich ist, 200 liefert und ein Rasterbild unter 1 MB serviert. Test mit OpenGraph Check und Facebook Sharing Debugger.

Dynamisches OG-Bild nach Publish aktualisieren?

Template ändern oder Cache per URL-Query busten. Plattformen cachen aggressiv; siehe Link-Vorschau-Cache erklärt.

og:image auf dynamische Route oder CDN-Kopie?

Direkt auf die dynamische Route mit starken Cache-Headern. Optional beim Publish ins Storage pre-rendern bei hohem Traffic.

Fazit

Dynamische Open-Graph-Bilder geben jeder URL eine passende Vorschau ohne manuelle Exporte. Nutze Next.js ImageResponse, cache die Ausgabe, halte Templates simpel und teste mit OpenGraph Check. Für Einzelgrafiken den OG-Bild-Generator. Für hunderte Seiten automatisieren.