How to set an OG image in Webflow

Webflow sites share through standard Open Graph tags. The Designer UI can set those tags per page; the failure mode is almost always “not published,” “wrong domain,” or “duplicate head code.” This guide stays in Webflow implementation territory—dimensions live on OG image size, universal failures on og:image not showing.

Webflow Open Graph workflow

1. Create a 1200×630 image (OG Image Generator or Image Resizer).
2. Open the Page settings for the URL you will share.
3. Fill Open Graph title, description, and image (upload to Webflow assets or use a full https URL).
4. Publish to your production custom domain—not only the .webflow.io staging host if customers share the custom domain.
5. Verify with View Source and the Link Preview Checker.
6. Re-scrape Facebook/LinkedIn after confirmation (debugger landing, Post Inspector landing).

Optional: check export weight with the Social Image Checker.

Static pages vs CMS

Surface	Approach
Static marketing pages	Set OG fields on each page
CMS template pages	Bind OG image/title/description to collection fields
Sitewide fallback	Use a default brand image only when a page has none

When binding CMS images, ensure the asset resolves to an absolute https URL in the published HTML. Relative paths fail outside Webflow’s designer preview.

Custom code caution

Webflow allows custom code in project or page head. If you paste a full Open Graph block while page settings also emit tags, crawlers may see two og:image values. Prefer native settings. If you must use code, remove the UI fields’ output or accept full ownership of the tag set.

Staging vs production

Crawlers and customers use the URL in the share. If you test only on yoursite.webflow.io but share www.yoursite.com, you fixed the wrong host. Align:

• Canonical / shared host
• Published Webflow domain settings
• SSL on the custom domain

Troubleshooting

1. Not published after OG edits → Publish.
2. Image missing in View Source → Re-check page settings on the correct page/CMS item.
3. Duplicate tags → Remove custom head duplicates.
4. Old image on Facebook → New asset filename + re-scrape.
5. WhatsApp-only failure → Compress (WhatsApp guide).
6. SPA-like embeds → Ensure tags are in HTML, not client-only widgets (React SPA guide if applicable).

Common mistakes

• Editing SEO fields but forgetting to publish
• Using a logo that is too small for a large card
• Sharing the Webflow subdomain while production differs
• Adding Helmet-like client scripts that never appear in View Source

Checklist

• OG fields set on the shared page/CMS item
• Published to the customer-facing domain
• One absolute og:image ~1200×630 in View Source
• Checker passed; platforms re-scraped after changes

Shopify: OG image in Shopify. Design guidance: OG image best practices.

CMS editors and client handoff

When handing a Webflow project to a client’s marketing team, document exactly where Open Graph fields live for static pages versus CMS items. Many failed previews are simply edits on the wrong page in the Designer. Include a two-minute Loom or written steps: open page settings, scroll to Open Graph, replace image, publish.

Localization introduces another trap: each locale subdomain or folder needs its own correct absolute URLs. A French page that still points og:image at an English asset is usually acceptable visually, but a French page that points at a staging CDN will fail. After enabling localization, sample View Source on each locale’s top share URLs.

If you export code from Webflow, re-verify meta tags in the exported head. Export workflows and hosting targets can drift from the hosted Webflow results you tested in the Designer.

Field notes from real share failures

Most broken previews are boring: a relative URL, a duplicate plugin tag, a cache that nobody re-scraped, or a file that is fine in Chrome but too heavy for a messenger. Resist the urge to rewrite the entire brand system until those basics are proven in View Source and a private window.

Write down the exact URL string you tested, including trailing slash and query parameters. Support threads go sideways when one person scrapes example.com/page and another shares example.com/page/. Treat the share string as part of the specification.

When you finally change artwork, change the path. Overwriting og.png in place is the most common reason a “fixed” card never appears. Pair the new file with a short note in your changelog so the next person knows which version is live.

Verification habits worth repeating

After every deploy that touches templates or SEO plugins, spot-check three URLs: the homepage, one article or product, and one utility page. Look for a single absolute og:image and open that file logged out. This ten-minute habit catches more regressions than redesigning share cards.

Document the owner of social tags for your stack—theme, plugin, or layout component—in the repository README. When something breaks, people should know which lever to pull first. Ambiguous ownership is how duplicate tags accumulate.

Finally, separate “works in our browser” from “works for crawlers.” If you only validate inside an authenticated preview session, you will ship failures to Facebook, LinkedIn, Slack, Discord, WhatsApp, and X without noticing until a campaign is live.

If you only remember one rule, remember this: crawlers are blunt. They fetch a URL, read tags, fetch an image, and cache aggressively. Your CMS preview, authenticated browser session, and hydrated React tree are not part of that path. Design the HTML and the image file for the crawler first, and human polish second. That ordering keeps share cards reliable while you iterate on the visible page design.