Do Client Photo Review Links Get Indexed by Google?
robots.txt, noindex, and an unguessable link solve three different problems — and only one of them is actually keeping strangers out.
A client photo review link is not private by default just because you never posted it anywhere. If the gallery tool skips two specific technical steps, a search engine can list that link days after you send it — right next to the couple's names, the model's face, or a brand's unreleased campaign. This happens more often with generic file-sharing links than with purpose-built proofing tools, because indexing was never a threat those tools were built against.
The short answer: a client photo review link gets indexed when nothing tells crawlers to skip it and nothing stops them from reaching it in the first place. Two mechanisms do that job — a robots.txt disallow rule and a noindex directive — and neither one is what actually keeps a stranger out. That's a third, separate thing: whether the link itself is guessable. This post walks through what each layer does, what it doesn't, and how to check your own galleries in five minutes.
How a client photo review link actually reaches Google
Crawlers don't go looking for private galleries on purpose. They find them the same three ways they find everything else on the web:
- A link from somewhere public. If a gallery URL gets pasted into a portfolio page, a tweet, a Facebook post, or even a webpage that later gets scraped and re-published, a crawler that indexes that public page will follow the link.
- A predictable URL pattern. Sequential or short IDs (
/gallery/1042) get discovered by crawlers that enumerate nearby paths, especially once one URL in the pattern is already indexed. - A sitemap that includes it by accident. Some site generators auto-list every route they know about, including ones meant to be private, unless someone explicitly excludes them.
None of these require the photographer to have done anything wrong. They require the gallery software to not have closed the door — which, for a lot of general-purpose file sharing, was never the job it was hired to do. A tool built for sending a document to one person and a tool built for delivering four hundred client photos that must never surface in a search result are solving different problems, even when the sharing mechanic looks the same on the surface.
robots.txt, noindex, and an access token do three different jobs
Once a link exists, three separate mechanisms decide what happens to it, and mixing them up is the most common mistake:
| Mechanism | What it actually does | What it does NOT do |
|---|---|---|
| robots.txt disallow | Asks well-behaved crawlers not to request the path at all | Nothing to stop a crawler that ignores it, or a human with the link |
| <meta name="robots" content="noindex"> | Tells a crawler that already fetched the page not to list it in results | Requires the crawler to fetch the page first — it can still see the content |
| An unguessable access token | Stops anyone without the link from reaching the page at all, crawler or human | Nothing — this is the one doing the real access control |
The first two are requests. They rely on the crawler choosing to cooperate, which the major search engines generally do, but "generally" is not a security boundary. The third is different in kind: it doesn't ask, it prevents. A link built as /willow-and-james-wedding/a1c9f2e8b3d74a90 is not indexed because nobody — crawler or curious stranger — can find that token by guessing, only by having received it.
The token is the one that can't just be ignored
This is the part worth sitting with: robots.txt and noindex are about search results, not about access. A page can be fully Disallow'd and still be viewable by anyone who has the URL. Blocking indexing answers "will this show up if someone searches for it," not "can someone I never sent this to open it."
For a client photo review link, both questions matter, but they're solved by different design decisions. Keeping the gallery out of search results is a crawler-facing rule. Keeping a stranger out of the gallery is a link-design decision made once, at the point the token is generated — long enough and random enough that guessing it is not a practical attack, with no sequential ID sitting next to it in the path. A tool that gets the second part right doesn't strictly need the first part to keep the photos safe from a stranger; it needs the first part to keep them from ever showing up as a search snippet with a client's name attached, which is a different kind of damage — reputational and contractual, not a break-in.
Revocation is the piece that neither robots.txt nor noindex touches at all. If a link needs to stop working — a shoot got cancelled, a freelancer's access should end, a wedding gallery outlived the couple's grace period — that has to be an explicit action the tool supports, not an assumption. A link that can be revoked in one click closes the door retroactively; a robots.txt rule only ever stops a future crawl.
A five-minute audit for the galleries you're already sending
You can check any gallery tool you're already using in about five minutes, without needing to be technical:
- View page source on a live client gallery link and search for
noindex. If it's not there, and there's no separaterobots.txtrule covering that path, the page is indexable by default. - Open
yourdomain.com/robots.txtdirectly in a browser and look for aDisallowline that would cover your gallery paths. If the file doesn't exist, or only disallows something like/admin, client galleries aren't covered. - Search
site:yourdomain.com "client's last name"for a shoot you delivered months ago. If a result comes back, that gallery is indexed right now, and this is the fastest way to find out before a client does. - Look at the URL structure itself. If two client galleries you've sent differ only by a short number or an easily-guessed slug, the token problem exists independently of whatever robots.txt says.
Run the site: search from step 3 on your three or four highest-profile past shoots first — a brand campaign, a well-known client, a wedding with an unusual name. Those are the ones a crawler is statistically most likely to have already picked up if a public page ever linked to them, and the ones where an indexed result is the most awkward to explain.
What this means for the tool you hand a shoot to
Generic cloud storage and purpose-built proofing tools make different tradeoffs here, mostly because they were built to solve different problems:
General-purpose file sharing
- Link permissions are usually "anyone with the link," with no separate crawler-facing rule
- No purpose-built canonical or noindex handling for shared folders
- Revoking access means changing folder permissions everyone with the link relied on
Purpose-built client review
- Share paths are closed to crawlers as a platform-level rule, not a per-gallery setting to remember
- Access is scoped to the one object being shared — a project, a folder, a single image — not a whole account or drive
- A link can be revoked without disturbing anything else the client has access to
Appruva's own share links follow the token-first approach described above: every share path collapses to a single robots.txt rule (any URL with a second path segment is disallowed, with the public marketing routes opened back up by name), and the page itself carries a canonical tag pointing at the homepage rather than the share URL, so there's nothing for a search engine to want to rank in the first place. That's a platform rule, not a checkbox a photographer has to remember to tick on every gallery. It's worth comparing directly against the tools you may already be using for delivery — see what breaks with Dropbox for client photo review and an honest look at Google Drive for proofing if either is currently doing this job.
None of this requires trusting a vendor's marketing copy. Every check in the previous section — view source, read robots.txt, run a site: search — works on any tool, including the one you're using today. Run it once per quarter on your active galleries, and once against your archive of everything you delivered in the last two years. A quarterly check on, say, six active shoots and a once-a-year pass on a backlog of forty delivered galleries is under an hour of work total — considerably less than the conversation that follows a client finding their own wedding photos in a Google search.
Fixing the rule doesn't erase what's already indexed
Fixing the rule doesn't undo an indexing that already happened. If a gallery was crawled and listed before you added a noindex tag or closed the path in robots.txt, the cached snippet and thumbnail can sit in search results for days to weeks after the fix goes live — a crawler has to come back, notice the page has changed or disappeared, and drop it, and that revisit isn't instant. Search engines generally offer a manual removal request for exactly this gap: a way to ask for a specific URL to be pulled from results immediately rather than waiting for the next crawl, separate from the robots.txt rule that prevents the next one.
This is the practical reason the fix belongs at the platform level rather than the per-gallery level. A photographer who remembers to add a noindex tag to this month's wedding gallery has still left every gallery sent before they thought of it exposed. A tool where every share path is closed by one rule, applied once, doesn't have a "did I remember this time" moment for a client to eventually stumble into.
Frequently asked questions
Can Google index a photo gallery link I never posted anywhere public?
Yes, if the link is guessable or sits in a predictable URL pattern next to pages that are already indexed. A crawler doesn't need you to have shared the link publicly — it needs to be able to reach it, whether by following a link from another page, enumerating a sequential ID, or finding it in a sitemap that wasn't scoped to exclude it.
Does putting a password on my gallery stop it from being indexed?
It stops a crawler from seeing the content behind the password, but a crawler can still discover and list the URL itself if nothing tells it not to. A password protects what's inside the page; it doesn't remove the page's address from a search index on its own. The two problems need separate fixes.
What's the actual difference between a robots.txt rule and a noindex tag?
robots.txt tells a crawler not to request a path at all — it can stop a page from ever being fetched. A noindex meta tag is read after the crawler has already fetched the page, and tells it not to list that page in search results. Using only one leaves a gap: robots.txt alone can still let content be seen if a crawler ignores the rule, and noindex alone means the crawler still downloaded the page before deciding not to rank it.
How do I find out if a client gallery I already sent is indexed right now?
Search Google for site:yourdomain.com followed by something specific to that shoot — the client's name, the project name, or a distinctive part of the URL. If a result appears, that page is indexed today. This takes under a minute per gallery and doesn't require any technical access to the site.
Is a long random token in the URL enough on its own, without robots.txt?
It's enough to stop a stranger from reaching the gallery by guessing, which is the access-control problem. It doesn't stop the URL from being indexed if a crawler finds it some other way — through a link, a referrer log, or a browser history sync — which is why the token and the crawler-facing rule are solving two different problems and a serious tool needs both.