Project Share Pages: One URL for a Multi-Artifact Handoff

Table of contents

1. When a project link beats an artifact link
2. The safe shape of a project share page
3. noindex is hygiene, not security
4. Expiry + revocation: plan the lifecycle
5. Publishing patterns: API vs MCP
6. A pre-share checklist

When a project link beats an artifact link

A single HTML artifact link is great when the deliverable is one thing: one report, one dashboard, one interactive summary.

A project link helps when the deliverable is a *bundle*:

• an executive summary + a detailed appendix
• a CI test report + a performance report
• a migration plan + a risk register + a checklist

In those cases, you do not want to paste five URLs into Slack and hope reviewers open them in order. You want **one handoff URL** that explains what the bundle is and points to the right artifacts.

If you are currently sharing multiple artifact links, start with Project Links for AI-Generated HTML Workflows and use the patterns below to keep the public share page safe.

The safe shape of a project share page

A project share page should not be “another artifact viewer”. It should be an index page that is safe even if it is shared widely.

A practical project share page includes:

• a plain title and short description (text only)
• a list of artifact entries: name, created date, and a link to view
• optional lifecycle controls applied server-side (expiry, revoked status)
• noindex + no-archive hygiene

What it should **not** include is arbitrary HTML content that the user (or an agent) can inject into the index page. Your artifact viewer is the place where untrusted HTML runs — inside a sandbox with security boundaries. The index page should stay static and non-executable.

This split matters: it reduces the blast radius of a project share link. Even if someone forwards the index URL outside your team, the index is still just an index.

`noindex` is hygiene, not security

Mark unlisted share pages as noindex (via a robots meta tag or the X-Robots-Tag header) so search engines do not index them. Google documents supported robots directives, and MDN documents X-Robots-Tag behavior.

But treat this as *hygiene*, not access control:

• crawlers must reach the page to see noindex, and behavior varies by crawler
• “not linked” is not a protection boundary — URL guessing and force-browsing are a known failure mode

OWASP’s Broken Access Control guidance is blunt here: every resource needs real access control, because attackers can and will modify URLs or directly request endpoints.

So use noindex, but always pair it with real controls: unpredictable share slugs, server-side authorization where appropriate, and revocation.

Expiry + revocation: plan the lifecycle

The easiest way to leak a share link is time: a link that was fine for a 30-minute review is still valid three months later.

Two defaults that work well for project share links:

1. **Revocation is one click** (or one API call).
2. **Expiry is optional but easy**: a share link can expire automatically after a date.

If you want a deeper workflow, see Expiry and Revocation: Make Unlisted HTML Links Safe to Share.

Publishing patterns: API vs MCP

BinHTML’s publishing split is about who owns the upload step:

• Use the API docs when your CI job or script already knows what artifacts to publish and which project they belong to.
• Use the MCP docs when an agent is still assembling the bundle and deciding what belongs in the handoff.

A practical pattern for multi-artifact handoffs is:

1. publish each artifact as it is generated
2. when the set is complete, produce (or update) the project index link
3. share only the project link in chat, tickets, or email

A pre-share checklist

Before you share a project link externally (or even across teams), check:

• The index page does not render arbitrary user HTML (text + links only).
• The artifact viewer remains the only place untrusted HTML executes.
• The share page uses noindex hygiene (and ideally no-archive).
• The slug is unguessable enough that you are not relying on obscurity.
• Revocation is immediate, and expiry is set when the share is time-boxed.
• The artifacts themselves are stable, self-contained, and safe to open.

Final thought: a project share link should make review easier *without increasing the security surface*. Keep the index page boring, and put the complexity where you can sandbox it.