How to Prevent Broken Website Thumbnails When a Domain Redirects
Fix broken link previews after a domain change by aligning redirects, canonical URLs, Open Graph metadata, and image access.
A domain redirect can leave a website thumbnail broken when the sharing platform reaches a different page or image than the one your site intends to share, or cannot fetch the image at all. Choose one preferred page URL, redirect alternate URLs to it, and make the final page’s canonical URL, og:url, and og:image agree. Then check the preview using the target platform’s own inspector when one is available.
A browser showing the page and image successfully does not prove a social crawler can fetch them. The crawler may encounter a redirect chain, contradictory metadata, a protected image, or a block on its fetch request.
1. Choose the URL the preview should represent
Decide which URL is the public destination for the page. For example, choose HTTPS and either the www host or the apex domain. Make alternate host and scheme versions resolve to that destination. Google recommends choosing a preferred URL and redirecting alternate versions to it; its guidance concerns Google Search and does not guarantee that every social platform follows redirects identically.
For a permanent domain move, use a permanent server-side redirect when possible. Google lists HTTP 301 and 308 as permanent redirects, and 302, 303, and 307 as temporary redirects. It describes redirects as a strong canonicalization signal and recommends permanent server-side redirects for permanently moved URLs. These are Google Search interpretations, not a universal specification for social preview crawlers.
| Redirect type | Use it when | Google Search interpretation |
|---|---|---|
| 301 or 308 | The old URL has permanently moved. | Permanent redirect signal toward the destination. |
| 302, 303, or 307 | The move is temporary and the source may return. | Temporary redirect; it does not provide the same permanent signal. |
Google says server-side redirects are the most reliable of the methods it lists and that HTTP redirects can have the quickest effect for canonicalization. A permanent redirect is not a substitute for consistent page metadata: keep internal links and canonical signals pointed at the same preferred URL.
2. Trace every redirect hop
Inspect the old shared URL and note each response status and Location destination. Confirm that the chain ends at the intended page, without a loop or an unexpected detour to a homepage, login page, or different host. This hop-by-hop check is a practical diagnostic; the sources here do not establish a universal redirect-chain limit for social crawlers.
curl -sS -L -D - -o /dev/null https://old.example.com/articleThis command follows redirects and prints response headers, including status lines and Location headers where provided. To inspect only the first response, omit -L. Repeat with the exact URL people share, including its path and relevant trailing slash.
Check common variants separately: HTTP and HTTPS, www and apex, and any old path that changed during the migration. Each should reach the intended final page. Avoid redirecting all old paths to the new homepage if the corresponding article still exists; that gives the crawler a different object to inspect.
3. Align canonical and Open Graph metadata on the final page
Open Graph defines og:url as the object’s permanent identifier and og:image as its representative image. Inspect the HTML head returned at the final destination, not just the old URL or the source template. The rel="canonical" link, og:url, and actual preferred page URL should be consistent.
<head>
<title>The article title</title>
<link rel="canonical" href="https://www.example.com/article">
<meta property="og:title" content="The article title">
<meta property="og:url" content="https://www.example.com/article">
<meta property="og:image" content="https://www.example.com/images/article-share.jpg">
</head>Replace the example URLs with the actual destination and image. Ensure the final response contains the intended values and that the image URL itself is not an obsolete-domain URL that no longer resolves. Open Graph is a protocol reference; individual platforms may apply their own fetching and preview rules.
4. Make the image publicly fetchable
Request the exact og:image URL and confirm it returns the intended image without requiring a logged-in browser session or access to a protected directory. Check that the image URL does not redirect to an error, expired signed URL, or HTML page. If the page loads in your browser but a platform omits its thumbnail, image accessibility is one of the first things to investigate.
LinkedIn specifically says blocking its image fetch or storing the image in a protected directory or site can prevent a preview image from appearing. Its documented sharing-module requirements list a maximum file size of 5 MB, minimum dimensions of 1200 × 627 pixels, and a recommended 1.91:1 ratio. These are LinkedIn requirements; they are not universal image rules for other platforms. Check the target platform’s current published requirements for its own limits.
5. Validate the preview after deployment
After updating redirects and metadata, inspect the exact shared URL with the platform’s official preview inspector or debugger when available. Check what the platform actually reads. A browser’s rendered page is not necessarily the same output a crawler receives, and one platform’s successful preview does not prove another platform will fetch it the same way.
If the final page and image now return correctly but a platform still shows an older thumbnail, its stored preview may be stale. Re-inspect using that platform’s own tool and follow its displayed refresh process. Cache durations and current debugger workflows vary, so do not assume a fixed refresh time.
6. Troubleshoot the common failure patterns
| Symptom | Likely cause | What to check or change |
|---|---|---|
| No thumbnail appears anywhere. | The final page has no usable og:image, or the image cannot be fetched. |
Inspect the final HTML head and request the exact image URL without an authenticated session. |
| The old site’s image appears. | The destination still emits old metadata, the old URL remains in og:image, or the platform has an older preview stored. |
Check metadata on the final destination, then re-inspect the exact URL with the platform’s official tool. |
| The preview shows the wrong page or site identity. | The redirect lands at an unintended host or path, or og:url disagrees with the destination. |
Record every redirect hop and align the final page URL, canonical link, and og:url. |
| The image works in a browser but not in LinkedIn. | LinkedIn’s image fetch may be blocked, or the image may be in a protected location. | Allow the fetch and make the image publicly accessible. Check LinkedIn’s published size and dimension requirements. |
| Some URL variants work and others do not. | HTTP/HTTPS, www/apex, trailing-slash, or path rules lead to different outcomes. | Test the exact shared URL and each relevant variant; route alternate versions to the chosen destination. |
| Redirects keep changing during a temporary migration. | A temporary redirect is being used for a permanent move, or the source and destination rules conflict. | Choose the redirect status based on whether the move is permanent, then make host and path rules consistent. |
7. Keep the migration reliable
- Maintain a mapping from each old page URL to its corresponding destination page.
- Use a permanent server-side redirect for a permanent move when possible.
- Keep canonical links,
og:url, internal links, and sitemap URLs consistent with the preferred destination. - Keep the preview image at a stable, publicly retrievable URL.
- Recheck representative old and new URLs after deployment, including the exact URLs people share.
- Validate preview output separately on each platform where the thumbnail matters.
Google’s redirect and canonical recommendations address Google Search. Social crawlers can differ, so the target platform’s own documentation and preview inspector are the authority for its output.
8. Or skip the browser setup
You can inspect a page or capture a clean screenshot through ScreenshotNeo, a website screenshot API and MCP server. A one-request example that saves the final destination page as WebP:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.example.com/article -o shot.webpSee the ScreenshotNeo API documentation for request options and formats.
- Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; each step can be turned off.
- Bot checks and CAPTCHAs, blank pages, failed loads, timeouts, and cache hits are never billed. Responses include
X-Page-VerdictandX-Billedheaders. - An MCP server provides
take_screenshot,get_page_info, andcapture_pdftools for Claude, Cursor, and other MCP clients. - The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card required.
Frequently asked questions
Does a canonical tag fix a broken social thumbnail by itself?
No. It helps identify the preferred page URL, but the platform still needs to fetch the final page and its image. Check the redirect destination, Open Graph tags, and image access too.
Should I keep the old domain after moving?
For a permanent move, Google recommends permanent server-side redirects from old URLs to their corresponding new URLs. The destination should carry consistent canonical and Open Graph metadata.
Are LinkedIn’s image dimensions the right dimensions for every platform?
No. The cited dimensions and file limit are LinkedIn’s documented sharing-module requirements. Consult each target platform’s own specifications.
How long should I wait for a changed preview to appear?
This varies by platform, and no universal cache duration is established here. Use the platform’s official preview tool to inspect or refresh the exact URL.
