How to share a preview without it turning up in Google

Sharing work before it is public is normal — a client draft, a pitch, a page for a launch that has not happened. What is not normal is finding it in search results afterwards, which is a genuinely bad afternoon when the thing was somebody else’s unannounced product.

The mechanics here are widely misunderstood, and the most common precaution people take is the one that does not work.

The robots.txt mistake

Almost everyone reaches for robots.txt and a Disallow rule. That controls crawling, not indexing — a different thing. Google will not fetch a disallowed URL, but it can still list it if it finds the address elsewhere, showing the bare URL with no description because it was never allowed to look inside.

Worse, the two mechanisms interfere. The instruction that actually removes a page from an index is noindex, delivered either as a meta tag or an X-Robots-Tag header — and both live in the response. If robots.txt has already forbidden fetching that response, the crawler never sees the noindex it was supposed to obey. Blocking crawling can therefore make a page harder to de-index, not easier.

What actually works

The reliable signal is the X-Robots-Tag response header. It applies to any file type, cannot be stripped by a page edit, and does not depend on the crawler parsing your HTML. A robots meta tag in the head does the same job for HTML and has the advantage of surviving if someone saves or mirrors the page.

Using both is the belt-and-braces version, and it is what FileShare Pro does on every shared response. A live check on any share link returns X-Robots-Tag: noindex, nofollow, noarchive, noimageindex, nosnippet, with a matching robots meta injected into the HTML. That is the default for everything hosted — you do not switch it on.

Why the link still previews in Slack

A page nobody can index would normally also be a page that unfurls as a naked URL in chat, which is a miserable trade for something you are actively sharing with people.

The way out is that link-preview bots are a separate population from search crawlers. The share host allows Slackbot, Twitterbot, Discordbot, facebookexternalhit, WhatsApp, LinkedInBot and TelegramBot specifically, while refusing everything else, so a preview renders for the people you sent it to without the page becoming findable.

Being straight about the limits

None of this makes a link secret. Anyone holding it can open it and can forward it, and no header prevents that. Treat the link as the access control: it is unguessable, and it can be switched off, which takes effect within seconds and cannot be undone by a cached copy because the edge is purged at the same moment.

One honest edge case: because the share host also refuses general crawling in robots.txt, a well-behaved search engine will not fetch a link and therefore will not read the noindex on it. If a share URL were published somewhere public and heavily linked, a search engine could in principle list the bare address it was never allowed to read. This is the flip side of the trap described above, and it is a reason to switch a link off when you are finished with it rather than relying on headers forever.

It is also worth knowing what other tools do by default here. A published Claude artifact, for instance, can be indexed by search engines — there is no password, no expiry and no visibility control, which is fine for showing a friend and wrong for a client deliverable.

A workable routine

• ✓Share the link directly with the people who need it, and do not post it anywhere public.
• ✓Keep revising on the same link rather than issuing new URLs that all stay live.
• ✓Switch the link off when the review is over — a finished draft left serving forever is the actual risk.
• ✓Check what you are relying on: curl -sI your-link should show an x-robots-tag line. If it does not, that host is not protecting you.