Create private internal pages your Google Workspace team can open.

Teams often need to share something more polished than an attachment but not complex enough to become a maintained internal app. An unlisted public URL is still public to anyone who obtains it, and adding custom authentication turns a small publishing task into application work.

• Public links are uncomfortable for internal material
• File attachments are hard to update and find
• Custom auth work slows down simple publishing

Create a workspace, publish a page, and share a URL that sends unauthenticated viewers through Google sign-in. The viewer boundary checks the signed-in email against the page policy before returning the page content.

• Company-wide sharing for common internal docs
• Selected-email grants for narrower review workflows
• Readable workspace and page slugs for links people understand

The audience determines the policy. Workspace access fits common team references and recurring reports. Selected-email access fits finance reviews, customer-specific pages, external collaborators, or any artifact whose audience is known and limited.

• Workspace access for a shared company knowledge surface
• Selected emails for narrower review groups
• Separate page slugs for different audiences or lifecycles

A publishing workflow is incomplete until both allowed and denied behavior are checked. Open the viewer URL signed out, sign in with an allowed Google account, then repeat with an account that should not receive the content.

• Signed-out visitors should be asked to authenticate
• An authorized account should receive the rendered page
• An unrelated account should be denied without page content
• Custom-domain URLs should enforce the same viewer policy

Authorized viewers receive the page in their browser and can inspect it. Never embed API keys, passwords, or credentials in HTML, Markdown, or OpenAPI source.

internalpage works best for browser-viewable, mostly read-only artifacts that are useful as a stable link. The source may come from a person, script, notebook, CI job, or coding agent.

• Generated HTML dashboards and test reports
• Rendered Markdown runbooks and decision notes
• Private OpenAPI references
• Temporary launch, review, and staging summaries

Use a dedicated application platform when viewers must edit records, maintain long-lived sessions, call a private backend at runtime, or receive permissions inside the application. Use an identity proxy such as Cloudflare Access when you already operate the origin and only need to protect it.

• Database writes and complex forms need an application backend
• Existing hosts may be better protected at the network or proxy layer
• Finished artifacts are the strongest fit for internalpage