If Open Graph tags appear in your browser but a social preview is missing or wrong, first check the HTML the public page sends before JavaScript runs. Then verify that the page and image are publicly fetchable, inspect redirects and crawler access, and refresh the cache for the platform showing the stale card. A browser’s live DOM, a generic preview checker, Google’s crawler tools, and a social platform’s scraper do not all test the same thing.
Why Open Graph tags work locally but fail online
Your browser can show a page after its JavaScript has run; a social crawler may read only the initial HTML response. A tag visible in DevTools’ Elements panel may therefore be absent from the document the crawler actually receives. OpenGraph Check describes its crawler-style check as reading raw HTML without executing JavaScript and looking for metadata in the document head (OpenGraph Check).
As an Amazon Associate I earn from qualifying purchases.
Local testing can also hide network differences. A crawler cannot reach your computer through localhost or a private LAN address. Even a working public tunnel tests that tunnel’s hostname, redirects, TLS and image paths—not necessarily production. The live public URL is the one to diagnose.
The Open Graph protocol defines properties such as og:title, og:type, og:image and og:url (Open Graph protocol). Their presence alone is not enough: the requested page must resolve to the intended content, and the image URL must be accessible to the fetcher.
Diagnose the exact public URL in order
-
Inspect the initial HTML, not just the live DOM
Use View Source in the browser or fetch the document with an HTTP client, then search for
og:title,og:description,og:image,og:urlandog:type. If tags are missing there but appear in Elements after page load, render page-specific metadata on the server or generate it statically. An app shell with metadata added only in the browser is not a dependable input for crawlers that do not execute JavaScript. -
Confirm the deployed page is publicly reachable
Test the exact HTTPS URL people will share from outside your development network. Check that DNS resolves, TLS works, the server returns a successful response, and the page is not behind a login, firewall rule or bot challenge. Follow redirects: an unintended redirect to a homepage, preview environment or error page can make the crawler inspect the wrong content.
For Google-specific fetch details, URL Inspection in Google Search Console can report returned HTML, headers, resources and fetch problems. Google documents failures including DNS or host-resolution problems, connection failures, invalid responses or SSL, inaccessible
robots.txtand host load. This tool diagnoses Google’s view; success there does not prove a social platform will fetch the page the same way (Google Search Console URL Inspection).Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Check crawler access without disabling security indiscriminately
Review
robots.txt, bot-specific access rules, your web application firewall, IP restrictions and image hotlink protections. Google notes that an unreachablerobots.txtcan prevent its crawl; a Facebook-focused guide describes allowing Facebook’s crawler as one troubleshooting measure (Facebook Sharing for Webmasters). Permit the relevant legitimate crawler or test safely against the public endpoint rather than turning off protections for every visitor. -
Test the image URL on its own
og:imageshould contain an absolute, publicly reachable URL. Open it directly without a logged-in session and confirm it returns an actual image, with an appropriate image content type—not a login page, denial response or broken asset. Check that it loads promptly and is not blocked by bot or hotlink rules. OpenGraph Check recommends 1200 × 630 pixels; treat that as a practical recommendation, not a universal platform requirement, and use the affected platform’s debugger to check its own result (OpenGraph Check). -
Compare the four versions of the page URL
Write down the URL submitted to the platform, the final URL after redirects, the page’s canonical URL and its
og:url. They should identify the intended shareable page, not accidentally point to the homepage or a different variant. Check that each content route emits its own title, description and image instead of inheriting generic defaults. Google URL Inspection distinguishes inspected, redirected and canonical URLs in its reporting; a social debugger may show its own fetched result. -
Refresh the cache after fixing the source
If the current public HTML and image are correct but a platform still shows an older card, use that platform’s own debugger or refresh control. The Facebook Sharing Debugger can show Facebook’s scraped tags and errors; its guide describes using “Scrape Again” to request a new scrape (Facebook Sharing for Webmasters). Cache behavior and refresh controls differ by platform, so do not assume refreshing Facebook also refreshes another service or rely on a universal expiry period.
Free tools Windows power users keep installed
One-click scans. No signup required.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Repeat the same test and keep the result
Recheck the public canonical share URL in the platform that displayed the problem. Note the tested URL, response status, redirect destination, metadata in the initial HTML, image response and debugger output. That record helps distinguish a delivery problem from a platform’s stored preview.
Match the symptom to the likely cause
| What you see | What to check | Next action |
|---|---|---|
| Tags appear in Elements but not View Source | Client-side metadata injection or the wrong HTML template | Return route-specific tags in server-rendered or statically generated HTML. |
| The preview shows the homepage or a generic title | Route defaults, redirects, canonical URL and og:url |
Make the requested, final, canonical and Open Graph URLs resolve to the intended content. |
| Title and description appear, but the image does not | Absolute image URL, public access, bot/hotlink rules, response type, loading and dimensions | Test the image directly without authentication, then inspect image-specific debugger warnings. |
| A checker cannot retrieve the page | DNS, server availability, TLS, authentication, firewall/WAF, robots access or overload | Fix the public fetch failure; use Google URL Inspection only as a diagnostic for Google, not as proof about a social crawler. |
| A local tunnel works, production does not | Production routing, response headers, image paths and security rules | Inspect the production response itself; a tunnel only demonstrates that the local service can be exposed. |
| A fresh check is correct, but the shared card is old | The target platform’s stored preview | Request a new scrape in that platform’s debugger after confirming the source is fixed. |
Choose the diagnostic tool that answers your question
- View Source or an HTTP client: shows the initial HTML delivered to a requester. It is the key check when the live DOM may have changed after JavaScript runs.
- A crawler-style preview checker: can quickly inspect raw tags, redirects, image retrieval or simulated previews. It is useful for comparison, but it is not the target platform and may not match its policies.
- The affected platform’s debugger: use it to inspect that platform’s current scrape and, where offered, request a refresh. A generic checker cannot establish what that platform has cached.
- Google Search Console URL Inspection: helps diagnose Google’s fetch and indexing view, including returned HTML and fetch problems. Google’s live test and indexed result can differ, and neither establishes social-preview success.
- A public tunnel: gives a remote checker an address for a local app. It does not demonstrate that production has the same hostname, redirects, certificates, image URLs or access rules.
Or skip the browser setup
If you need to inspect the public page’s screenshot alongside its response, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a screenshot or PDF; it does not replace checking raw Open Graph HTML or the target platform’s own cache. Its capture process accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups and chat widgets by default; each step can be turned off. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads and cache hits cost nothing, and responses identify the page verdict and billing status in headers. AI agents can use its MCP server tools, including take_screenshot, get_page_info and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/article -o shot.webp
Replace the URL with the publicly deployed page you want to inspect. The result is a screenshot, so separately inspect the initial HTML and validate the share card in the affected platform’s debugger. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month with no card.
Frequently Asked Questions
Does a successful Google URL Inspection test prove social previews will work?
No. It reports Google’s fetch or index view; social platforms use their own fetchers and preview caches.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
