The request lands with whoever approves tools. Sales wants to publish AI-generated pricing pages as links, marketing wants campaign previews, and operations wants a dashboard the leadership team can open from a phone. The HTML is already moving through paste sites, email attachments and whatever host was open in a tab. The approver has to pick a path that still looks reasonable after a customer's security questionnaire.
This enterprise HTML sharing checklist takes that evaluation in order: the content you share, the options in front of you, six criteria to test, what the audit record answers, a trial that checks the claims, and the habits that keep people on the approved path. HTMLvault is the worked example throughout, including the things it does not do.
Start with the content you actually share
Start from your own traffic, not the vendor demo. List what your teams sent outside the company last month by type: AI-generated reports, proposals with pricing, dashboards, lead lists, landing page previews, training pages. HTML hides more than it shows. A generated dashboard can carry the source rows behind its chart, a pricing page can hold a test token in a script block, and an exported table can include an email column nobody meant to send.
Classify each type with the tiers your sharing policy already uses, and let the tier choose the controls. A confidential proposal should not get the settings of a public event recap just because both are HTML. If the tiers and their owners are not written down yet, settle that first; the governed AI sharing platform guide covers who owns what. This checklist assumes the policy exists and tests whether a tool can carry it out.
Then ask the failure-mode questions, because the answers decide how much tool you need. Are secrets showing up in generated pages? Are customer emails sitting in HTML source? Are links living forever? Can search engines reach any of it? Can anyone review what the team published last week? A team that answers no to all five may only need individual accounts. A team that answers yes to three needs shared rules and a record.
For anything sensitive, keep the original internally and share a sanitized copy. The client gets a readable page without every internal figure that produced it. Sanitizing means deleting the value from the HTML. Hiding it with CSS is not redaction: a display: none row is still in the page source for anyone who opens developer tools. HTMLvault drops HTML comments when it stores a page, but it keeps hidden elements, data- attributes and script text exactly as written.
Three options and what each costs: a paste site, an attachment, a governed link
Most teams are already choosing among three paths, even if nobody calls it a choice. Each one fails in a different place.
A paste site is fast and asks nothing of the sender, and that is its weakness. The URL is the only access control, the page usually stays up until someone deletes it, it may be crawled and indexed, and nobody learns who opened it. The step it skipped was the one where someone decided who should see the content and for how long.
An attachment feels private and needs no new tool. Once it lands, the sender loses track of it. It gets forwarded, saved to laptops, and stripped or quarantined by mail filters. Fixing a mistake means sending a second file and hoping people delete the first. The sender never learns where it went.
A governed link keeps the content on a surface you still control. It can expire and ask for a password. It can carry one tracked URL per recipient, so a forward shows up, and it keeps a record of opens. You can also correct the page after sending without changing the URL. The costs are an account to set up, settings someone has to own, and a vendor to approve.
Six criteria to test: lifespan, access beyond the URL, a check before publish, the crawler default, evidence, policy without policing
These six criteria are the core of this enterprise HTML sharing checklist. They cover what a tool does before a page is sent, after someone opens it, and when something goes wrong.
1. A lifespan the sender sets
Ask for the range, not the feature name. One fixed window can't serve both a 24-hour review link and a training page that stays up all year. In HTMLvault, expiry is set per link in fixed steps. On Pro and above the range runs from 1 hour to 1 year or never, and the MCP tool offers the same steps except 1 year. Free links expire after 30 days. You can change or extend an expiry after the link is sent, so a slipped deadline does not mean a new URL. Choosing an expiry window covers how to match the setting to the work.
The other half of lifespan is retention: how long the content and its view data stay stored after a link expires. In HTMLvault it is one account-wide setting, 7 days to 2 years on paid plans, counted from each link's expiry. Org members use the org owner's setting. When the window runs out, the page and its per-visitor view data are deleted. There is no per-link retention and no organization-wide cap on expiry. If a tier needs a maximum lifespan, write it into the policy and check it in review, because no setting enforces it. More in shared link data retention.
2. Access beyond the URL
An unguessable URL is not access control; it is obscurity with good manners. Look for two layers on top of it. Password protection is the first. In HTMLvault it is available on Pro and above, set per link on the web and checked on the server. A correct password unlocks the page in that browser for up to a day. Changing the password ends every earlier unlock, so you can cut off a forward without changing the URL. The second layer is one tracked URL per recipient. If a recipient forwards their copy, the new reader shows up as unfamiliar views on that person's link.
When you test, treat signing in and viewing as separate questions. SSO/SAML (included on Enterprise, an add-on on Teams) controls who can sign in to HTMLvault to publish and manage links. It never restricts who can view one. Sign-in uses one-time email codes, passkeys, Google or Apple, so there are no account passwords to reuse. SSO can't meet a requirement like "only employees can open this page." On the viewing side, the controls are the password, per-recipient links and a short expiry.
3. A check before publish
The cheapest moment to catch an API key in a generated dashboard is before the link exists. Ask whether the tool inspects every publish and every edit or only the first upload, and what happens when it finds something. HTMLvault checks each publish and edit against the account's PII and secret policy. That policy is a regex scanner covering nine categories: SSNs, financial data, API keys, passport numbers, addresses, person names, dates of birth, emails and phone numbers. It costs zero tokens to run. HTMLvault also checks every outside URL in the page against Google's unsafe-URL lists. When a publish is refused, the sender gets the findings back instead of a URL. On Teams and Enterprise, Publishing Rules decide which findings block a publish, and they can treat password-protected pages differently from public ones.
The scanner catches obvious mistakes. It does not classify data or make legal calls. An internal floor price or a draft discount matches no pattern, so the content inventory has to come before the tool.
4. The crawler default
Shared pages should stay out of search without anyone remembering to tick a box. Every HTMLvault link is noindex, a tag that tells search engines not to list the page. Also ask what a link shows when someone pastes it into Slack or an email. HTMLvault uses the page's title, description and image for the preview card only while the link is open. A password-protected, expired or removed link shows that status on the card and nothing from the page. Neither behavior stops a recipient from forwarding or taking a screenshot, so these criteria have to work together.
5. Evidence
Two people want evidence for different reasons. The sender wants to know whether the proposal was opened and read past the pricing table. The approver wants to know what the scan found, when the page was fixed, and who saw it before the fix. Ask whether both records exist and whether they survive a personnel change: a record that lives in one rep's inbox leaves with the rep.
6. Policy without policing
Individual judgment does not scale across a sales team publishing hundreds of pages a month, so look for rules that apply themselves. In HTMLvault the shared controls come with Teams and Enterprise:
- Publishing Rules for scan findings
- folders shared with everyone, a role or named people
- custom roles
- the PII audit log
SSO/SAML is included on Enterprise and an add-on on Teams, so confirm which identity setup your security team requires before you price the tier. Expiry and passwords are set link by link by whoever publishes. The policy for those is written guidance plus the review described at the end of this post.
What the audit record should answer, and what analytics cannot
A creation log is not an audit trail. It tells you a link was made, not whether the link put anything at risk. Before you trust any tool's audit feature, write down the questions the record has to answer:
- When was the page published, and what did the scan find?
- When was it edited, and what did the scan find on that edit?
- Who opened it, through which recipient's link, and when?
- Can you prove whether anyone opened it before you fixed it?
- Who changed its password or expiry, and who deleted it?
HTMLvault answers the first four from two records. The PII audit holds one scan event per publish or edit, with the scan's findings. Per-link analytics hold the views: when the link was opened, unique and repeat viewers, time on page, scroll depth, country and city, device and referrer. With per-recipient links, they also show whose link each view came through.
The fourth question settles what happens after a mistake. Suppose a proposal goes out with an internal floor price in a table column hidden by CSS. The next morning the account team removes it with a patch, which keeps the URL. The patch's scan event gives the time of the fix. The link's analytics show whether any views came before that time, and through whose link. Instead of "we think nobody saw it," you can answer with a timestamp.
HTMLvault cannot answer the fifth question. Nothing records password changes, expiry changes, deletions or changes to the retention setting. Before rollout, decide where those decisions get written down: a change ticket, the exception register described below, or the request thread that approved the share. Once you know the gap, a simple process closes it.
Analytics have limits too. They show that a page was read, not why; a long time on page is context, not intent. They show which link a view came through, not who was holding the device. They also disappear with retention. When the account's retention window closes after a link expires, the per-visitor view data is deleted along with the page, so record anything you need as evidence before then. The view data that helps a sales rep tailor a follow-up is, for a limited time, also your proof of which link was opened and when.
Run the trial like an approver
A demo shows the path the vendor picked. Your trial should test the paths your team will actually use, on the plan you would actually buy.
Try the plan you would buy. Free plans cap volume and lock the settings an approver cares about. HTMLvault's Free plan allows 50 links a month with a 30-day expiry and no passwords. Publishing Rules, the PII audit log and BYOK AI scanning start at Teams. Before you decide the tool cannot do something, make sure you weren't testing a plan you would never buy. Check that the plan fits your rollout before you compare prices. One team that needs to stop using paste sites may be fine on individual Pro accounts. A company-wide standard needs the shared folders, roles and rules of Teams (10 seats included, more as the team grows) or Enterprise. The cheapest option stops being cheap once it starts generating security exceptions.
Check that the API can do what the UI does. Your teams may publish from Claude, ChatGPT or Cursor through MCP (the protocol AI assistants use to call tools), or from Zapier, Clay or a script through the REST API. If so, run the trial through those paths too. The scan applies to every publish and edit, whichever path it comes from. Plant a fake API key in a test page and confirm each path returns the same findings. Then note the differences you will plan around:
- Passwords are set on the web only, in the upload form or the links dashboard. MCP and the REST API cannot set one.
- Retention is an account setting on the web. It cannot be set through MCP or the API.
- MCP
create_linkoffers every expiry step the web does except 1 year. - To preview findings without publishing, use the
scan_htmlMCP tool. There is no REST scan endpoint, so a script only learns about findings when it publishes. - A large page built in append mode runs no checks until the draft is finalized, and nothing in it is public until then.
update_linkis refused on a draft.
Read the record a week later. Publish a test link, open it from two devices, patch it, change its expiry, and delete a second test link. A week later, try to piece together what happened from what the tool shows you. In HTMLvault, the PII audit shows the publish and the patch with their findings, and the link's analytics show both visits. The expiry change and the deletion appear nowhere. Now you know which decisions your own change record has to cover.
Ask who pays for AI scanning. If a tool advertises AI detection, ask where the tokens come from and when the scan runs. HTMLvault's regex scanner is not a model and costs nothing to run. On Teams and Enterprise, an optional AI scan reviews a link after it is published, using your own Anthropic, OpenAI or Google API key. HTMLvault never pays for those tokens, so the cost and the data terms sit with your AI provider account. Either setup can work, but a vendor should be able to tell you which one it uses. The PII scanner buyer's guide compares what each layer catches.
Make the approved path faster than the workaround
If the approved path means downloading a file, opening a portal, filling in a form and waiting, people will paste the HTML somewhere faster. The checklist then becomes a document nobody follows.
Put the approved tool where the HTML is made. With HTMLvault's MCP server, someone working in Claude, ChatGPT, Gemini or Cursor asks the assistant to publish, and the page comes back as a link that has already been scanned. Automations use the REST API with an API key. A Zapier step or a script can publish a report as soon as it is generated, or create up to 100 personalized pages from one template in a single call. When the numbers change, the page is replaced or patched in place and the client's URL keeps working, so a correction never means a second attachment. A branded subdomain or custom domain makes the approved link look like something the company sent on purpose.
Train by role, using decisions people will recognize. Show the sales team what to do with a pricing page that contains a customer's contact details. Show engineers how a token ends up in generated output and what comes back when a publish is refused. Show marketers how an "unlisted" page on a general-purpose host can still turn up in search. Three short examples do more than an annual deck of 47 slides and a quiz everyone completes while reheating lunch.
Review cadence and exceptions
Review on a schedule: monthly for the first quarter, then quarterly. Look at what people actually published, not just what the policy says. AI tools change what they produce quickly. A prompt that returned a paragraph last quarter may now return a full HTML report with embedded rows and links to internal systems.
Look for patterns in refused publishes and exception requests. If the scanner keeps flagging a legitimate placeholder, such as a sample phone number in a template, tune the rule so people don't learn to work around it. On Teams and Enterprise, that means changing the Publishing Rules. If people keep asking for longer expiry, find out why. The expected window may be unrealistic for the sales cycle, or the requests may point to a process that needs tighter control.
Write every exception down, with an approver and an end date. Because HTMLvault does not log password, expiry or deletion changes, the exception register is also where those decisions live: who allowed a never-expiring link, for which page, and until when. Without an end date, an exception quietly becomes the policy.
The setup proves itself the first time someone asks whether a client saw the wrong version. You compare two timestamps, the patch's scan event and the link's first views, and answer in one sentence.