Open Graph Repair Checklist + Free Report

Start with the page you actually share

Run a free check, review the observed metadata and image evidence, then use the report options below the result to keep the findings and next steps together. Basic diagnostic results remain available so you can start fixing the page.

The checklist combines automated evidence with manual checks. OG Fixer does not reproduce a social platform's renderer or promise that a passed metadata check will update an existing post.

1. Confirm the page identity and access

• Use the public page URL, including any query string that changes its content.
• Check the final URL after redirects. Confirm it is the page you intended to share.
• Review the HTTP response. A login page, challenge or error response does not establish access to your intended content.
• If a request could not be completed, keep its state as unknown or failed. Do not interpret the absence of findings as a successful check.

2. Check the metadata in fetched HTML

The Open Graph protocol defines og:title, og:type, og:image and og:url as its four basic required properties. A useful og:description provides additional context.

Check the returned values, not only whether a field name appears somewhere in your source. A page title or fallback description does not prove that its OG counterpart is declared. Update the page's existing metadata so its tags agree.

<meta property="og:title" content="Your page title" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://example.com/your-page" />
<meta property="og:image" content="https://example.com/share.jpg" />
<meta property="og:description" content="A useful page summary." />
<meta property="og:image:alt" content="Describe the image." />

This is an example, not a replacement for page-specific values or the metadata API in your framework. Set a suitable content type and canonical page identity for the page you are editing.

3. Verify the image response and composition

• Confirm that the declared image URL serves an accessible image, not an HTML error or sign-in response.
• Use measured pixel dimensions when the checker can read a supported image header. This is not a complete visual validation. A file's byte length or an HTTP header inspection does not establish its width and height.
• Make declared width and height match the real file. A practical 1200×630 starting size is a recommendation, not a universal validity rule.
• Check the platform-specific size guidance and compare the simulated crops.

Record decoding or fetch limitations as limitations. An image that works in your logged-in browser can still be unavailable to a public fetcher.

4. Separate a missing preview from an old preview

A missing tag, blocked resource and stale platform card need different repairs. If the live source still points to the old asset, fix that first. If the source and image are current, use the destination app's inspection workflow.

The old-image diagnosis guide covers this sequence. For Facebook and LinkedIn, the debugger guide links to their official inspectors. Test a fresh share in the relevant app after the repair.

5. Hand off a repair someone can verify

A useful handoff contains the checked page and time, the specific observed value or error, the intended value, the file or CMS field to change when known, and a clear recheck step. If you do not manage the website, share this with its owner.

6. Recheck the affected scope

Run a fresh check after publishing the fix. If a shared template caused the problem, include other representative pages. Save the completed results so you can compare real observations from before and after the change.

The bulk checker checks up to five submitted pages and exports JSON or CSV. It reports that selected scope; it does not silently certify the rest of the website.