Why your links share as a bare URL, and how to fix the preview image

What the error means

A page without a valid og:image (or with one that fails to load, is too small or is an unaccepted format) shares to social platforms and chat apps as a bare URL or a broken thumbnail. Twitter needs the twitter:card family or falls back to Open Graph; Slack, WhatsApp, LinkedIn and Facebook read og:image only.

Why Google rejects it

Every platform unfurls a link by fetching its own copy of the page and the image (never the browser cache, and often a different user agent that your CDN may block). That is why a preview can look fine for you and broken for everyone else: their fetcher is a bot, and bot rules apply to it.

How to fix it

1. Add og:image to the page head pointing at an absolute https URL. Relative paths and http images are ignored by several platforms.
2. Use 1200×630 PNG or JPG, under about 5 MB. SVG is not rendered by any major platform; an SVG og:image is the same as none.
3. Keep the image publicly reachable: no login walls, no hotlink protection, no expiring signed URLs.
4. Fix caching after a change: platforms cache aggressively. Use their debugger (Facebook Sharing Debugger, PostInspector for LinkedIn) to force a refetch.
5. Add twitter:card (summary_large_image) so X renders the large card instead of falling back.

Common causes

The image field is unset on the affected template

A home page may have a social image configured while product, collection or article templates do not. OpenGraph metadata is emitted per URL, so one page can have a working preview while another shares as a bare link. Compare the actual source for a failing URL with a page that previews correctly.

The page uses a relative or non-public image URL

Social fetchers request the image without your browser session. A relative path, login-protected asset, expiring signed URL or hotlink restriction can fail when the platform fetches it. Check the exact URL from a private browser and confirm it returns the image publicly over HTTPS.

The image format or dimensions are unsuitable

Some sharing services do not render every image format, and a very small or unusually shaped image can be rejected, cropped badly or omitted. Shipwork's guide recommends a 1200 by 630 PNG or JPG under about 5 MB. Review the image dimensions and file type, not just the page tag.

A CDN or security rule blocks the preview bot

A page or image can load for you but return a challenge, 403 or throttling response to an automated unfurl request. Check CDN and server logs for requests to both the page and its image around the time a preview fails. Do not assume that allowing a search crawler automatically allows every social platform fetcher.

The platform is showing a cached preview

Social and messaging services reuse fetched metadata. Replacing an image at the same URL may leave an old thumbnail until their cache refreshes. If source code and the image are correct, use the platform's sharing debugger where available.

Fix it on your platform

On Shopify

1. Inspect the page source for the exact product, collection or page URL and search for og:image; do not assume the store-wide social image applies to every template.
2. For a product-specific preview, use the product image or the theme/app setting that controls that template's social image. Check the active theme's head output before adding another tag.
3. If you change theme code, use the theme's supported Liquid metadata pattern and keep the image URL absolute. Avoid editing a copied snippet that is not used by the published theme.
4. After saving, load the public URL and open the referenced image in a private window. Shopify admin preview access does not prove a sharing bot can fetch it.

On WooCommerce

1. Check the social or Open Graph image setting in the SEO or social metadata plugin that emits tags for the failing post or product.
2. If no plugin provides a page-level value, set a site default and confirm the theme outputs a single og:image tag in the page head.
3. Clear page and CDN caches after changing metadata, then inspect the public page source to confirm the new absolute image URL is present.
4. Check media library permissions and image optimization or hotlink settings if the image URL returns an error to an outside request.

On other platforms

1. Wix: open the affected page's SEO/social sharing settings and set its share image; then verify the published page source, not only the editor preview.
2. Squarespace: review the page's social image or social sharing image field and any site-wide social image fallback. Check which value is emitted for that specific URL.
3. BigCommerce or a custom site: inspect the active theme's page head or SEO app output and set an absolute public image URL for the page type.
4. For any platform, test the page and image from outside the admin session and refresh the social platform's cached scrape after correcting it.

How to confirm it is fixed

1. Open the exact shared page as a logged-out visitor and inspect its source for one correct og:image value.
2. Open that absolute image URL directly. Confirm it returns the intended image without a login, redirect to HTML, or access challenge.
3. Use Shipwork's social preview check on the affected page to inspect the OG and Twitter tags and test the image URL.
4. Refresh the cache with the relevant platform debugger where available, then share the link in a fresh conversation to confirm the preview changed.

Other errors like this