Steamworks adding external links means placing URLs anywhere Steam will render them—store page descriptions, the Basic Info fields specified in Valve's documentation, developer/publisher profiles, and community hub panels—so players can reach your website, forum, or online guide; every URL must begin with http:// or https://, and bare or malformed links are the most common cause of silent rejection. This explainer covers how the validator works, what counts against you, and where the threshold sits between a link players value and a link Valve removes.
The short answer hides a longer mechanism. Valve does not publish a comprehensive link policy, so the rules you actually face are a mix of documented field requirements, automated validation, and moderation judgment applied unevenly across store pages, demos, and community spaces. Understanding each layer separately is what separates a link that survives review from one that gets truncated or flagged.
How the link field actually validates a URL
Every text field in Steamworks that accepts a URL runs through the same pipeline: client-side input formatting, server-side schema validation, then human or automated moderation review before the page goes live or updates.
The first layer is mechanical. The field expects a protocol prefix, so a string beginning with www. or a bare domain fails schema validation and the field will not save or the update will be rejected at build time. This is why the http:// or https:// requirement exists as a hard rule rather than a style preference; the parser is anchoring on the protocol token to distinguish a link from plain text. A second undocumented behavior: ampersands and query strings are sometimes stripped or rewritten by the store renderer, so tracking parameters appended to a product URL can vanish after publication. If you need to measure referral traffic from Steam, plan for that loss rather than assuming the full URL survives.
The second layer is field-specific. Valve's store page documentation lists dedicated fields for a website and support URL, plus the "External Link" field used in the Basic Info editor, and each has its own character budget. Overflow does not error gracefully; the field truncates, and a truncated URL is a dead link that players will report. The practical lesson is to paste the final, complete URL and confirm it after saving rather than typing it inline.
The third layer is moderation. Links inside the long description and the "About This Game" block pass through review, and policy for outbound destinations is applied by judgment rather than a published list. This is the layer most developers misread, because a link that publishes cleanly on one page may be removed after a later moderation pass.
What external-link policy actually targets
Valve's documented prohibitions center on the store page rather than on links as a category. The rules bar commercial content, advertising, fundraising, and links that circumvent Steam's own commerce systems. Community guidelines add that off-topic or promotional content can be removed from hubs and discussions.
The distinction that matters: pointing players to your own official forum or guide is generally treated as player-relevant information, while pointing them to a page engineered to move a transaction off Steam is treated as circumvention. The API and licensing documentation reinforces the commerce boundary—content delivered through Steamworks is expected to route transactions and entitlements through Steam's systems.
One counterintuitive detail that trips up publishers: a link can be technically valid, render correctly, and still be removed because of what sits on the destination page, not on Steam. An affiliate parameter, a countdown timer, or a storefront widget on your "official site" can convert a player-information link into a commercial one in a reviewer's eyes. The link itself is never the whole object of review; the landing experience is.
Where players can actually reach your links
Not all link surfaces carry the same weight or the same risk. Store page fields sit closest to commerce and attract the most scrutiny. Profile and hub surfaces sit closer to community and tolerate more, though they can be moderated for spam signals.
Store page Basic Info fields: dedicated website and support URLs; highest visibility, highest review attention. Store description and About This Game block: narrative links render as text; published policy bars commercial destinations here. Developer and publisher homepages: outbound website links survive more reliably than store-description links. Community hub panels: guide, forum, and discussion links are conventional and rarely challenged unless flagged. Steam News and event posts: links to patch notes and guides are treated as editorial content, not advertising. Steam Workshop item descriptions: links inside user-content boxes follow the Workshop rules, not the store rules.
The pattern is directional. As you move from store fields toward community surfaces, tolerance for outbound links rises and the enforcement mechanism shifts from schema validation to reactive moderation.
Edge cases that break naively correct links
Edge cases cluster around protocol, encoding, and localization, not around policy.
Mixed content is the first. An http:// link embedded in an otherwise secure flow can be rewritten or blocked depending on context, so https:// is the safer default even though http:// is explicitly allowed. Redirect chains are the second: a shortener or a vanity URL that bounces through two hops can be flagged as suspicious or lose its parameters, so link to the final destination. The third edge case is character encoding—non-ASCII characters in a URL must be percent-encoded, and pasting a raw Unicode path frequently fails validation or renders mangled.
Regional variants deserve their own note. The store page is localized, and a single external link field does not branch per language, so a link to an English-only guide appears unchanged for every regional visitor. Developers who maintain separate regional sites often solve this by pointing to a language-selector landing page rather than a deep link.
A caveat worth stating plainly: the exact moderation threshold for a given link type is not published, and behavior observed on one page does not guarantee identical treatment on another. Treat observed outcomes as data points, not rules.
Comparison: link surfaces and their tolerance
| Surface | Typical link types | Validation strictness | Moderation exposure |
|---|---|---|---|
| Basic Info website/support fields | Official site, support | High (schema + format) | Moderate, review-gated |
| Store description / About | Guides, patch notes | Medium (format only) | High, published prohibitions |
| Developer/publisher homepage | Website, forum | Medium | Low unless reported |
| Community hub panels | Forum, guides | Low | Reactive, spam-flag driven |
| Steam News posts | Guides, changelogs | Low | Reactive |
| Workshop item descriptions | Mod guides, tools | Low | Reactive, user-report driven |
Read the table left to right as increasing distance from commerce. The stricter the validation, the more predictable the outcome; the looser the validation, the more you rely on moderation judgment staying quiet.
Timeline: what happens between paste and publication
| Stage | What occurs | Typical elapsed time |
|---|---|---|
| Input formatting | Client checks protocol prefix; rejects bare domains | Immediate |
| Schema validation | Server confirms field format and length | Seconds |
| Build/review | Page or update enters Valve review | Hours to a few days |
| Publication | Link renders; URL may be rewritten | At approval |
| First player reports | Broken or stripped links surface | Days to weeks |
| Post-publication moderation | Link reviewed after complaints or a sweep | Weeks to months |
The gap between publication and post-publication moderation is the operational hazard. A link can go live, gather click-through, then be removed weeks later, which makes broken-link monitoring a maintenance task rather than a launch task.
Practical actions before you publish
Work in order, from the hardest constraint outward.
First, decide which link belongs in which field. Put the support destination in the dedicated support field, keep the store description free of commercial destinations, and reserve guide and forum links for community surfaces. Second, confirm every URL is the final destination with https:// and no redirect hops, and re-paste it after saving to catch truncation. Third, test the link from a logged-out browser and a mobile client, since rendering differs.
Fourth, add a lightweight quarterly audit: crawl your store page and hub panels, follow each link, and log status codes. A single missing redirect on a decommissioned guide can linger for months. Fifth, for anything you cannot afford to lose, keep a copy of the target content on a Steam surface itself—a News post or hub guide—so the player-facing path survives if an external link is removed. Sixth, when a link is rejected or removed without explanation, resubmit through the support channel with the exact destination and a short rationale rather than tweaking the URL and hoping.
The professional caveat bears repeating here: because the moderation layer is judgment-based and unpublished, no checklist guarantees approval. Build for the cases you can control—format, final destination, surface choice—and monitor for the ones you cannot.