Public share link leads to unintended search engine indexing in Adobe XD

Answer first

Revoking or changing an Adobe XD public share from "Anyone with the link" to "Invite Only" stops new server-side access to the share page, but it does not instantly purge cached copies that already exist in browsers, CDN edge nodes, or search engine indexes. There is no documented Adobe XD admin action to force immediate invalidation of downstream caches for a revoked link. Remediation relies on natural expiration plus search engine removal tools.

Confirmed facts vs likely explanation

Confirmed with caveats: Adobe XD is discontinued and reached end-of-support. Current platform behavior and admin controls may differ from historical documentation and should be verified against the latest Adobe notices. Public share links are enforced server-side; once the sharing setting is changed, unauthenticated requests to the share URL should be denied.

Likely explanation: Cache lifetime for assets served via a public link is governed by HTTP cache headers and CDN configuration, not by the share-link state itself. Once an asset has been served publicly, a CDN edge or browser can continue to serve the cached response until its TTL expires, even if the origin now requires authentication. Search engine indexing is separate from application cache. If a public URL was crawled, results can remain visible until the engine re-crawls or a removal request is processed.

Factors that influence how long assets remain reachable

• HTTP response headers for the share page and embedded assets: Cache-Control, Expires, ETag, and max-age. These set browser and intermediate cache TTL.
• CDN edge caching policy used by Adobe Creative Cloud delivery. Edge nodes honor origin headers and their own TTL.
• Browser and proxy caches of users who previously opened the link.
• Search engine crawl frequency and index retention. Indexing persists independently of your sharing setting.
• Direct asset URLs. If the indexed URL is a direct asset URL rather than the share page URL, revoking the share may not block access if the underlying storage URL remains unauthenticated.

Scoped steps for this case

1. Confirm the sharing state is changed to Invite Only and the share link now requires authentication. Attempt access in an incognito window.
2. Check the HTTP headers for the share page and representative assets. Look for Cache-Control, Expires, and Age. This indicates intended TTL, not a guarantee of instant purge.
3. Search the exact public URL in major search engines to see if cached or indexed copies remain after revocation.
4. If the URL is indexed and sensitive, use search engine removal tools. For Google, use the URL Removal tool for temporary removal and request recrawl after the page returns a 403/401. For Bing, use the Bing Webmaster Tools URL removal.
5. Document the URLs that remain accessible and monitor them until they expire or are removed.

One diagnostic detail that changes the recommendation: Are the indexed URLs the share page, e.g. https://xd.adobe.com/view/..., or direct asset URLs such as images or preview files served from a CDN path? If direct asset URLs are indexed and remain unauthenticated, revoking the share link alone will not block them and additional review of asset exposure is needed.

Assumption and uncertainty: Behavior described reflects historical Adobe XD sharing and CDN practices. Because XD is end-of-support, current enforcement and header values cannot be verified here and may have changed. No admin purge API for XD caches is documented in available knowledge.