In one paragraph
An og:image relative URL points to a path rather than a complete image address in the metadata this check reads. Some preview consumers resolve such paths, but do not rely on consistent handling. Publish a valid absolute HTTPS image URL, confirm the public resource is retrievable, and test the target sharing platforms. An absolute string alone does not guarantee a successful preview.
Why it matters
Open Graph describes a page as an object for social and sharing consumers. Its image property identifies the representative image. The protocol's URL type uses HTTP or HTTPS, so a full address is the interoperable form to publish.
A path that works as an ordinary browser image reference may not be handled identically by a metadata scraper. A consumer can also reject a valid absolute address because of authentication, access rules, response format, download limits, or caching. Separate metadata syntax from resource delivery.
This finding concerns preview reliability, not a direct guarantee about ordinary search indexing or ranking. A good share image can communicate the page effectively, but publishing the tag does not force every platform to display the same card.
How WebAuditOS evaluates this finding
The supplied rule checks a non-empty og:image value from served HTML for an http:// or https:// prefix, case-insensitively. A matching prefix passes; other forms fail at low severity. Missing or empty values and error pages are not graded here.
It does not fetch the file or validate dimensions, MIME type, content, or bot access. The documented implementation inspects the last image value when several are present, whereas the Open Graph protocol gives preference to the first root value during conflicts. A scanner pass can therefore differ from what a consumer selects. Leading whitespace and protocol-relative forms can also fail its literal prefix test.
How to fix it
- Inspect every og:image declaration in source order. Identify whether a theme, plugin, framework metadata API, or custom snippet owns it. Review associated structured properties after each image rather than treating all image-related tags as one value.
- Emit a full address from trusted production configuration. For example:
<meta property="og:image" content="https://example.com/images/share-pricing.jpg">Replace the host and file with a real publicly accessible image. Do not build the value from an unvalidated incoming request host or leave preview-environment URLs in production.
- If your framework accepts relative metadata inputs, confirm the final rendered output resolves them to absolute URLs using the intended metadata base. A relative configuration object is not necessarily a relative published tag; inspect the actual HTML.
- Use an appropriate supported image and accurate optional properties. Content type, dimensions, and descriptive og:image:alt can help consumers interpret it. Check platform-specific requirements rather than assuming one universal pixel or file-size rule.
- Request the file while signed out and through the public delivery path. Verify successful status, correct bytes, valid TLS, and absence of interactive login or challenge requirements. An HTML error page returned at an image URL is not a usable image.
- If multiple images are intentional, publish them in a coherent preference order with the right structured properties following each root image. Do not merely put one valid absolute image last to clear the scanner while leaving an invalid preferred image first.
- Test relevant platforms with their inspection or refresh tools where available. Previews can remain cached after a repair; distinguish stale output from current metadata.
- Rescan and verify representative deep pages, languages, and preview deployments. Make each image relevant to its destination rather than giving every shared URL an unrelated generic graphic.
What the fix can break
Hard-coding the production origin can make a preview page reference an image that has not yet been deployed there. Keep environment behaviour deliberate and test launch dependencies.
Bots can encounter access restrictions different from your signed-in browser. Do not disable necessary protections broadly; make the intended public image path correctly accessible.
Changing image order can alter which preview appears even if all files work. Coordinate creative changes separately from the syntax repair so the resulting card remains accurate.
Questions
Is a protocol-relative URL enough?
Publish an explicit HTTPS address for clarity and interoperability. The supplied check rejects protocol-relative values.
Does an HTTP image pass?
The described prefix test accepts HTTP, but HTTPS is the appropriate choice for modern public delivery. Passing does not validate the file.
Why did the scanner and platform choose different images?
The documented check reads the last value, while Open Graph preference starts with the first. Consumers and caches can add further differences.
Which related checks help?
Review Open Graph tags, og:url, and card metadata.