OG-Bilder in großem Maßstab

Die Erzeugung von og:image in großem Maßstab bedeutet, für jede Seite einer großen Website – Tausende von Blogbeiträgen, Produkten oder Dokumentationsseiten – automatisch eine eindeutige, korrekte Social-Preview zu erstellen. FastOG rendert jedes Bild bei Bedarf (1 Render) und Cloudflare cached identische URLs dauerhaft, sodass der Maßstab weder Kosten noch Einrichtungszeit vervielfacht.

Das Problem mit einzigartigen Bildern in großem Maßstab

Das manuelle Erstellen von Tausenden von 1200×630-Bildern ist nicht praktikabel. Die meisten Teams greifen auf eine generische Karte für die gesamte Website zurück – eine verpasste Chance, denn eine pro Seite erstellte Karte mit dem tatsächlichen Titel erzielt mehr Shares und Klicks. Die Lösung ist deterministisches Rendering auf Abruf: Das Bild wird zur Renderzeit aus den Daten der Seite selbst abgeleitet.

Warum FastOG skaliert

Die Kernidee sind inhalts-signierte, gecachte URLs:

Sie signieren eine URL aus dem Seitentitel + Feldern zur Renderzeit (eine reine Funktion des Inhalts).
Der Crawler ruft die URL einmal ab; FastOG rendert das PNG (1 Render) und cached es am Edge.
Jeder spätere Abruf derselben URL wird aus dem Cache bedient — sofort und nicht gezählt.

So zählen 10.000 verschiedene Seiten einmal 10.000 Renderings, und unbegrenzte Shares kosten danach nichts.

Stapelweise / systematische Einführung

Um og:image auf einer gesamten Website einzuführen, generieren Sie die URLs zur Build-Zeit oder beim Veröffentlichen für jede Seite:

tsx

// Static generation — generateMetadata per route
export async function generateStaticParams() {
    return posts.map((p) => ({ slug: p.slug }));
}

export function generateMetadata({ params }) {
    const post = posts.find((p) => p.slug === params.slug);
    return {
        openGraph: {
            images: [generateOgImageUrl({
                template: "blog",
                title: post.title,
                subtitle: post.excerpt,
                author: post.author,
            })],
        },
    };
}

Muster, die Skalierung kostengünstig halten

Muster	Warum es hilft
Signieren zur Build-/Renderzeit	Deterministische URLs → gemeinsames Caching
Wiederverwendung einer Vorlage pro Inhaltstyp	Konsistente Marke, weniger Designentscheidungen
Caching identischer URLs	Wiederholte Shares zählen nicht
Generierung bei Veröffentlichung, nicht bei jeder Anfrage	Vermeidet Kalt-Renders beim ersten Share

FAQ

Wie viel kosten 1.000 oder 10.000 Seiten?

Ein Render pro eindeutigem Bild. 10.000 eindeutige Seiten = 10.000 Render einmalig; unbegrenzte erneute Freigaben kosten nichts. Siehe Preise für Dynamic-API-Pläne.

Was ist mit Seiten, deren Inhalte sich häufig ändern?

Jede Inhaltsänderung erzeugt eine neue URL und einen neuen Render (1 Quotenverbrauch). Stabile Seiten bleiben im Cache.

Kann ich OG-Bilder während eines statischen Builds generieren?

Ja – viele Teams generieren und speichern die Bild-URL zum Build-/Veröffentlichungszeitpunkt (SSG), sodass es beim ersten Teilen nie einen Cold Render gibt.

Kostenlos testen – keine Anmeldung erforderlich

Vorschau und Test dynamischer OG-Bilder in Sekunden.

Kostenlosen OG-Bild-Tester öffnen

Thema