Social preview monitoring for content & web teams

Check Open Graph metadata after each deploy.

Add ShareScan checks to GitHub Actions and connect scan results to a release. Review metadata issues and changes so engineering and content teams can follow up from the same evidence.

Start with a free scan. No account or credit card. Then choose weekly follow-ups by email or Slack for up to 10 report pages.

Paste a page, a domain, or up to 10 URLs, one per line.

See what the report shows

A clear place to start

See the issue. Find the page. Follow up.

  1. Check the sourceInspect titles, descriptions and images in the metadata your pages serve.
  2. Review the findingsOpen affected pages and use the issue details to decide what needs fixing.
  3. Check again after changesRun another scan after a fix, or set up recurring checks for the pages that matter.

Previews are based on fetched metadata. Slack, LinkedIn and X may show a different or cached card.

ShareScan / Preview reportActual product view
A ShareScan report showing a metadata score, checked pages and findings from a scan of sharescan.io.
A real scan of sharescan.io, captured 8 October 2026. A dated snapshot of three pages, not a live status.

From finding to fix

What to check and how to follow up.

Check 01

What CI metadata checks solve

Many preview regressions are introduced by deployment changes, not content edits.

Why it happens

  • Template updates changing og:* output unexpectedly.
  • Static asset or CDN changes invalidating social images.
  • Redirect or canonical updates that alter destination URLs.

What to do next

  • Trigger ShareScan checks immediately after deployment jobs complete.
  • Fail or flag workflows when high-severity metadata issues appear.
  • Attach report links in build output for rapid triage.
Check 02

How to use pass/fail and diffs effectively

Binary status is useful, but teams need field-level change context to fix quickly.

Why it happens

  • No diff view between current and previous healthy release.
  • No shared visibility outside engineering tooling.

What to do next

  • Inspect issue-level diffs after every failed check.
  • Post workflow outcomes into Slack for marketing and web stakeholders.
  • Maintain a baseline set of critical URLs for release quality gates.
Check 03

Setup checklist for reliable post-deploy scans

CI checks are most useful when URL selection and alert routing are explicit.

Why it happens

  • Workflows scan too few URLs or only non-production environments.
  • Results are not routed to an owning team.

What to do next

  • Use the ShareScan GitHub Actions workflow template as a starting point.
  • Include core campaign and revenue URLs in every run.
  • Connect Slack to set up preview alerts for launch-critical channels.

When your team needs broader coverage

Bring recurring checks into your publishing workflow.

Create a workspace and verify your domain to schedule scans, manage URLs and connect CMS or GitHub Actions triggers. The Free workspace plan covers up to 100 pages.

Create free workspaceCompare monitoring plans

Before you start

A few useful details.

Should Open Graph checks run before or after deploy?

Post-deploy checks confirm real production output and catch environment-specific issues that pre-deploy tests can miss.

Can GitHub checks show exactly what changed?

Yes. ShareScan reports include issue-level findings and change context so teams can diagnose regressions fast.

Can results go to Slack automatically?

Yes. Connect Slack to set up alert routing for the channels that own launch quality.

How does this relate to scheduled monitoring?

GitHub checks cover deploy moments. Scheduled monitoring covers ongoing drift between releases.

Explore a related check

More ways to keep previews in view.

Open Graph Monitoring & Alerts

Combine CI checks with recurring scans and alerting.

Open Graph Checker

Validate core OG field quality before integrating CI.

Slack Link Preview Checker

Scan Slack unfurls and continue preview alert setup in Slack.