ogmake
Sign up

OG images in WordPress

A plain functions.php hook has nowhere safe to keep a signing secret — it's plain PHP in your theme's source, often synced or backed up in the clear — so the signed GET /i/{keyId}/{sig} route (Signing) isn't a good fit here. A public key works with nothing more than add_action and the post's own fields.

1. Create a public key

Sign in at /login, open the dashboard, check which templates the key may render (e.g. blog), then "Create public key". The key id (starts with k_) is safe to hard-code in your theme.

Still on a hand-issued beta key? Email support@ogmake.com.

2. Hook it into wp_head

In your theme's functions.php: 

function ogmake_meta_tags() {
    if ( ! is_single() ) {
        return;
    }
    $params = array(
        'site'   => 'example.com/blog',
        'author' => get_the_author(),
        'date'   => get_the_date( 'M j, Y' ),
        'title'  => wp_strip_all_tags( get_the_title() ),
    );
    $url = 'https://ogmake.com/p/k_yourkeyid/blog?' . http_build_query( $params );
    printf(
        '<meta property="og:image" content="%s">' . "\n",
        esc_url( $url )
    );
}
add_action( 'wp_head', 'ogmake_meta_tags', 5 );

Gotcha: an SEO plugin is probably already printing an og:image tag

Yoast SEO, Rank Math and similar plugins hook wp_head too, and by default they'll emit their own og:image from the post's featured image (or nothing, if there isn't one) — most browsers and crawlers use the first matching tag, so whichever hook fires first wins, and having both can produce an inconsistent preview across platforms. The priority 5 above runs before most SEO plugins' default priority (usually 10); to be sure yours wins, disable the plugin's own social image output for the post types you're covering (most SEO plugins have a setting for this) rather than relying on hook order alone.

Verify it

View source on a published post (curl -s https://yoursite.com/some-post/ | grep 'og:image') and confirm exactly one og:image tag is present. A bad or missing field on the public route is still a 200 fallback image, not a visible error — curl -I the image URL itself and check for x-ogmake-error (see debugging a public URL). If a page-caching plugin (WP Rocket, WP Super Cache, host-level full-page cache) is active, purge the cache before re-checking — a stale cached HTML page will keep serving the old tag regardless of what functions.php now outputs. Then run the live URL through Facebook's Sharing Debugger or LinkedIn's Post Inspector; if you edit a post without changing title/author/date, the image URL is identical and the crawler's own cache can still show the old preview — append a v query param (e.g. get_the_modified_time()) to force a fresh scrape.