Google Discover and Article schema image sizes (16:9, 4:3, 1:1)

Google Discover asks for a hero image at least 1200 px wide, 16:9, and more than 300,000 total pixels. Article structured data asks for the same picture in three shapes, 16:9, 4:3 and 1:1, each at 50K pixels or more. You can ask the Sume image API for each ratio with the aspect_ratio field and a model that lists it.

Both numbers come from Google's own documentation, read 2026-10-10. This post lines them up, then shows how to produce the set without hand-cropping in a design tool.

What Google asks for, side by side

The two pages describe different surfaces. Discover is the feed on a phone, where a large preview image drives the click. Article markup is the image property that search features can use to pick a thumbnail. Google states the Discover rules as recommendations, and tells you to opt into large previews with the max-image-preview:large setting (or AMP). You can also name the preferred image with schema.org markup or an og:image meta tag.

The math for a safe export size

A 1200 px wide 16:9 image is 1200 x 675, which is 810,000 pixels, comfortably over the Discover floor of 300,000. The two Article rules are far looser: 50K pixels is about 224 x 224 for a square, so any sensible export clears it.

That means the binding constraint is width on the 16:9 file. Generating at 1200 px wide or larger covers Discover, and the 4:3 and 1:1 variants can come from the same prompt rather than a crop of the wide frame.

Generating the three ratios with the Sume image API

The Sume images docs list bytedance-seed/seedream-4.5 with an aspect_ratio enum of 1:1, 16:9, 9:16, 4:3 and 3:4. All three ratios Google wants are in that list. Because each call is a fresh generation, keep the prompt text identical so the three files read as one picture family, then check the framing before you publish.

POST /v1/images blocks for up to 30 seconds and then returns a 202 job envelope, so the loop below handles both. Poll /v1/jobs/:id/status for any ratio that comes back queued.

import os
import requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
prompt = "calm desk with notebook and coffee, soft window light, wide editorial photo"

for ratio in ("16:9", "4:3", "1:1"):
    r = requests.post(
        "https://api.sume.com/v1/images",
        headers=H,
        json={
            "model": "bytedance-seed/seedream-4.5",
            "prompt": prompt,
            "aspect_ratio": ratio,
        },
        timeout=60,
    )
    body = r.json()
    if r.status_code == 202:
        print(ratio, "job queued, poll /v1/jobs/:id/status")
    else:
        print(ratio, r.status_code, body["data"][0]["url"])

Check the output before it ships

Run each file through your own size check, because the aspect ratio field requests a shape and does not promise an exact pixel count. Confirm the 16:9 file is at least 1200 px wide before you point og:image at it. If a file comes back smaller, ask for a higher resolution tier supported by the model's descriptor in /v1/images/models, or regenerate.

• Serve the 16:9 file as og:image and as the first entry in the Article image array.
• Add the 4:3 and 1:1 files to the same array so Google can pick the shape a feature needs.
• Set max-image-preview:large in your robots meta tag, since Google ties Discover large previews to it.
• Keep image URLs crawlable and indexable, per the Article page.

Using a video frame as the hero instead

If the article embeds a clip, you can pull a still from it rather than generate one. Video frames takes a media.sume.com clip and an at[] list of times, and returns durable image artifacts at source size when you leave max_edge off. A 1920 x 1080 source gives a 16:9 still above the 1200 px rule with no resampling.

Remember that frames keep the source's shape, so a vertical clip yields a vertical still. For that case, generate the 16:9 hero with the image API and keep the frame for the 1:1 or social crops.

What this does not cover

Neither Google page promises that a correctly sized image will be shown in Discover; both are guidance. Sume produces files that meet the stated sizes, and nothing here changes how Google ranks or selects them. Treat the table as a pre-publish checklist and verify in Search Console after the page is indexed.