Quick answer
If your page looks correct in a browser but Slack shows no preview image, the problem is usually not "Slack is random." It is usually one of four things:
- the page HTML does not expose a stable
og:imageURL; - Slackbot cannot fetch the image publicly;
- the image route returns headers, redirects, or content Slack does not handle well;
- Slack is showing a cached result from an earlier fetch.
For most indie sites, the fastest fix is to debug in this order:
confirm og tags in raw HTML
-> fetch the image URL directly
-> check status, content-type, size, and redirects
-> make sure the image is public and stable
-> reshare after Slack cache time
Who this is for
This guide is for solo founders, indie hackers, and small product teams who ship marketing pages, blog posts, tool pages, or Product Hunt assets without a big growth team behind them. If you are using static pages, framework-generated metadata, or a dynamic OG image endpoint, this is the failure mode that wastes half a day: the preview looks fine in one place, but Slack still shows a blank card or the wrong image.
What changed and why this matters now
A July 3, 2026 Show HN post about Wax Spinner described a familiar launch problem: the site worked, but social preview behavior across crawlers was inconsistent, and Slack was one of the hardest platforms to satisfy. Slack's own docs explain the stable part of the story: Slack unfurls links by fetching them with Slackbot, not with the viewer's browser session, and it caches unfurl results for around 30 minutes. The practical lesson is simple: treat Slack preview debugging as a fetch-and-delivery problem, not a design problem.
The practical workflow
1. Check the raw HTML first
Open the page source or fetch it directly:
curl -I https://example.com/post
curl -L https://example.com/post | rg 'og:image|og:title|og:description'
You want a full absolute og:image URL in the HTML that Slackbot can read without running app code in a browser tab.
If your page depends on client-side rendering before the OG tags appear, fix that first.
2. Fetch the image URL directly
Take the exact og:image URL and test it as a standalone asset:
curl -I https://example.com/og-image.jpg
curl -L https://example.com/og-image.jpg -o /tmp/og-test
file /tmp/og-test
Check these basics:
- status is
200 OK; - final URL stays on HTTPS;
- content type is a normal image type;
- the file is not blocked behind cookies, auth, or signed sessions;
- the route does not bounce through unnecessary redirects.
If the image itself is unreliable, the preview will be unreliable too.
3. Check route stability and platform fetch assumptions
Slack's docs tell you the fetch happens from Slack's side. The HN Wax Spinner debugging story adds a useful field pattern: dynamic image routes can fail for reasons that are not obvious in a browser, especially when global middleware, CDN rules, or security headers are attached to the image response.
Treat these as review items:
- does the image live at a clean, durable URL;
- is the route public without a user session;
- do redirects preserve the final image correctly;
- are global response rules accidentally applied to image endpoints;
- does the route behave differently for bots than for browsers.
Dynamic OG images are fine, but they need to behave like stable public files.
4. Check image quality, not just image existence
Google's image guidance and Discover guidance are not Slack-specific, but they are still useful guardrails:
- use a large, high-quality image;
- keep the image crawlable;
- make sure the image matches the page's main topic;
- avoid tiny logos as the only preview asset.
5. Re-test with IndieSeek's own tools
Before you blame Slack, make sure the page metadata is correct in the first place.
- Use OG Image Checker to inspect the image URL and preview assumptions.
- Use Meta Tag Checker to verify title, description, canonical, and OG tags together.
These are the two fastest internal links for this problem because the issue is often half metadata, half delivery.
A compact decision tree
Is the wrong image showing everywhere?
Yes -> fix the page metadata first.
No -> continue.
Is Slack showing no image at all?
Yes -> fetch the exact og:image URL directly.
No -> continue.
Does the image URL return 200, public access, and a normal image type?
No -> fix the asset route.
Yes -> continue.
Does the route depend on auth, signed params, or fragile redirects?
Yes -> make it stable and public.
No -> continue.
Did you just change the image?
Yes -> wait for Slack cache to refresh, then test again.
No -> inspect headers and middleware on the image route.
Common mistakes
The first mistake is validating only in a browser. Slack fetches from Slack's infrastructure, so "works on my laptop" is weak evidence.
The second mistake is using relative or late-injected OG tags. The crawler needs stable HTML and stable absolute URLs.
The third mistake is serving the image through a route that behaves like an app endpoint instead of a public asset.
The fourth mistake is changing the image and immediately resharing the same link without accounting for Slack's documented cache window.
FAQ
Does Slack use my browser session to render previews?
No. Slack's docs describe server-side fetching and unfurl behavior from Slackbot.
Do I need a static image file, or can I use a dynamic OG endpoint?
You can use a dynamic route, but it has to behave like a stable public file: normal status code, public access, predictable redirects, and an image response Slack can fetch cleanly.
Should I care about Google image guidance for this?
Yes, as a supporting rule set. Google and Slack are different systems, but large, crawlable, relevant images are a good baseline for both search and sharing.
Sources and related resources
- Slack link unfurling docs: https://api.slack.com/reference/messaging/link-unfurling
- Slack robots and crawler user agents: https://api.slack.com/robots
- Google image SEO best practices: https://developers.google.com/search/docs/appearance/google-images
- Google Discover image guidance: https://developers.google.com/search/docs/appearance/google-discover
- Google Article structured data reference: https://developers.google.com/search/docs/appearance/structured-data/article
- OG Image Checker
- Meta Tag Checker
- Show HN: Wax Spinner, a "now playing" social app for vinyl record collectors (2026-07-03): https://news.ycombinator.com/item?id=48774122
Top comments (0)