Monitor Open Graph Metadata After Every Deployment

What should an Open Graph monitor check?

Repeat the same scoped checks: the returned page and final URL, declared metadata, image access, and dimensions when supported image headers can be read. Save the results and review new failures or unintended changes.

A completed fetch establishes evidence about that response. It does not prove a social app's final card, a particular deployment commit, or the health of every URL on the site.

Choose a small, useful first scope

Pick a homepage, a conversion page and representative content pages that use different templates. If you maintain client sites, keep each client's URL list and saved results separate.

The free bulk endpoint accepts up to five public URLs per request. Start with that bounded set. Do not describe a five-page check as a complete crawl of a larger website.

[
  "https://example.com/",
  "https://example.com/pricing",
  "https://example.com/articles/launch"
]

Save your own list as og-pages.json. Use unique public URLs without credentials or private tokens. Replace the example domain before running a check.

Run the same audit from your release workflow

With Node.js 24, save this as og-check.mjs beside the URL list. It calls the same bulk endpoint as the browser tool and saves the returned evidence. An incomplete run or an error finding produces a nonzero exit code; warnings stay in the report for review.

import { readFile, writeFile } from "node:fs/promises";

const urls = JSON.parse(await readFile(
  new URL("./og-pages.json", import.meta.url), "utf8"
));
if (!Array.isArray(urls) || urls.length < 1 || urls.length > 5
    || urls.some((url) => typeof url !== "string")) {
  throw new Error("Use an array of 1–5 public page URL strings.");
}

const response = await fetch("https://ogfixer.com/api/audit/bulk", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ urls }),
  signal: AbortSignal.timeout(90000),
});
if (!response.ok) {
  throw new Error("Audit request failed: HTTP " + response.status);
}
const report = await response.json();
if (report.schema !== "ogfixer.bulk.v1" || !Array.isArray(report.results)
    || report.requested !== urls.length || report.results.length !== urls.length) {
  throw new Error("Unexpected audit response; no passing result established.");
}
await writeFile("og-check-result.json", JSON.stringify(report, null, 2));

const incomplete = report.complete !== true || report.checked !== urls.length;
const blocking = report.results.some((item) =>
  item.status !== "checked" || !Array.isArray(item.report?.findings)
  || item.report.findings.some((finding) => finding.severity === "error")
);
console.log(report.checked + " of " + urls.length + " pages checked.");
console.log("Read og-check-result.json for findings and limits.");
process.exitCode = incomplete || blocking ? 1 : 0;

node og-check.mjs

Add that command after your deployment has succeeded and the intended public URLs are available. Keep og-check-result.json as a private build artifact if it contains client-specific information. The script writes one result file; retaining run history is a separate step in your CI setup.

This is a starting policy for the checks returned by the service. Review the findings and limits before deciding which conditions should block your own release.

Keep failures, recommendations and unknowns distinct

Do not hard-code “exactly 1200×630” as a universal validity test. The Open Graph protocol defines image metadata; destination apps have their own guidance. Use the image-size reference to choose a suitable design.

Comparing a saved image URL or dimension does not prove that the bytes at an unchanged URL stayed the same. Only make content-change claims when your workflow actually records the evidence needed to support them.

Choose a trigger you can rely on

A deployment-triggered check helps catch changes you just published. A scheduled check can also detect later resource failures. Choose a frequency that fits the number of pages and service limits, and route actual failures to the person responsible for the site.

If you use GitHub Actions, its workflow-event documentation explains that scheduled runs can be delayed and, under load, dropped. A cron expression alone is not an exact-time guarantee. Confirm a real run completed before describing a monitor as active.

For a maintained product workflow, review the current setup and capabilities on the monitoring page. A one-time bulk result is a snapshot; ongoing checks require a configured repeat workflow.

Use an agent without losing the evidence

The free MCP endpoint lets a compatible client audit a public URL, request reviewable fixes or validate the fetched evidence. Give the agent an explicit page list and ask it to retain the requested URL, scope, findings and proof gaps.

Each current MCP tool performs a fresh page audit. Use the tool that fits the job instead of automatically running all three for every page. A recommendation does not authorize the agent to change or publish your website.