Steamworks accepts external links through a specific, limited set of fields, and most developers fail because they paste raw URLs into fields that only accept formatted text. Your website, forum, and online guide links have designated homes in the Steamworks backend, and each field has its own validation rules. The practical answer: add your product website under Store Page settings, your forums under Community settings, and your guide as a Steam guide or a whitelisted external URL, always starting with http:// or https://. This explainer covers the exact mechanism, field-by-field, with the thresholds that actually trip submissions.
Steam's link handling is not one system. It is at least four separate systems with different parsers, different whitelists, and different failure modes. Understanding why they diverge is the difference between a link that renders as clickable text and a link that silently disappears on the live store page.
Mechanism: how Steamworks parses and validates external links
Steamworks runs every URL through a shared validator before it reaches the store surface. The validator checks three things in order: the protocol prefix, the domain against an internal whitelist, and the string length against the field's column limit. A URL that fails any check is rejected at input time in most fields, but in a few fields it is accepted and then stripped at render time. That second behavior is the source of most "my link vanished" reports.
The protocol check is strict and literal. The parser looks for the exact characters h-t-t-p, followed by either a colon and two slashes or a colon and one slash. Uppercase HTTP:// passes because the check is case-insensitive at the character level, but a missing colon, a missing slash, or a bare domain like example.com fails. There is no auto-prefixing. If you type your domain without https://, the field either rejects it or stores it as plain text that never becomes a hyperlink.
The domain whitelist matters more than most developers expect. Steam's store description parser and several community fields restrict outbound links to a set of known domains. Common documentation hosts, major video platforms, and first-party Steam URLs pass. Unknown domains, URL shorteners, and raw IP addresses typically do not. Shorteners are blocked deliberately because they obscure the destination, which is a phishing and moderation problem.
The length check is the quiet killer. Different fields have different character ceilings, and a long campaign-tracking URL with query parameters will exceed a store field limit even though the same URL works fine in a forum post. The fix is consistent: strip tracking parameters, use the shortest canonical form of the URL, and prefer path-based links to query-based ones.
Plain language: Steam only turns your text into a clickable link if it recognizes the exact format and trusts the domain, and every field has its own rules.
Quantified context: which fields exist and what they accept
The Steamworks backend exposes external linking through a small number of named fields and surfaces. The important ones for a product launch are the store page's website link, the community hub's forum and guide surfaces, and the developer/publisher homepage links shown on the store page sidebar.
The store page website field accepts a single canonical URL and displays it as a labeled button on the right rail of the store page. It expects the full https:// prefix. It does not accept multiple URLs. If you need to surface a forum and a guide and a website, the website field holds one, and the others go elsewhere.
The community hub is where forums live. Steam creates a hub per product, and discussion forums are native to that hub. You do not add a forum link so much as you enable and configure the hub's discussion boards, then optionally point the store page's community link at the hub. Third-party forums, such as a Discord server or an external phpBB board, are not hosted by Steam and generally cannot be placed in the store page website field as a substitute.
The online guide surface has two paths. The native path is a Steam Guide published under the game's community hub, which Steam hosts and indexes. The external path is a URL to an external guide, which must clear the whitelist to render on the store page. In practice, native Steam Guides are the reliable route because they inherit the hub's trust and do not depend on a third-party domain surviving the whitelist.
For the numbers: the website field holds one URL, typically under a few hundred characters. Store description fields cap total text length per field, and long URLs count against that cap. A campaign URL with five tracking parameters can easily run past 200 characters, which is why canonicalization matters. These are structural limits rather than published thresholds, so treat any specific character count as field-dependent and verify in the backend preview.
Comparison: native Steam surfaces versus external links
| Link target | Where it lives | Protocol requirement | Whitelist sensitivity | Reliability |
|---|---|---|---|---|
| Product website | Store page sidebar field | https:// required | Domain must clear store parsing | High if canonical |
| Steam forum | Community hub discussions | Not applicable (native) | None (first-party) | Highest |
| Steam Guide | Community hub guides | Not applicable (native) | None (first-party) | Highest |
| External guide URL | Store description or hub text | http:// or https:// required | High; unknown domains stripped | Medium |
| Discord or chat invite | Hub text where permitted | https:// required | Often restricted | Low to medium |
| Video walkthrough | Store description or hub text | https:// required | Platform-dependent | Medium |
| URL shortener | Anywhere | https:// required | Usually blocked | Very low |
The pattern is clear. First-party Steam surfaces are the most reliable because they bypass the external whitelist entirely. Every external link trades reliability for reach, so place your most important destinations on native surfaces and treat external URLs as supplements.
Edge cases: redirects, parameters, and regional formatting
Redirect chains break more links than bad domains do. A URL that resolves through two or three hops may pass validation at the first hop and fail at render time if the final destination is not whitelisted. Use the final canonical URL, not a redirector. This is especially common with marketing platforms that wrap every outbound link in a tracking redirect.
Query parameters are accepted but risky. A parameter-heavy URL can exceed a field's length limit, and some parsers treat certain parameter patterns as suspicious. Strip everything after the path unless the parameter is functionally required, such as a language selector or an embed flag. Analytics parameters belong in your own analytics, not in a public store link.
Regional formatting causes silent failures. A URL with a locale path segment can render differently across store regions, and a link that works in one region may resolve to a localized page that lacks the content you intended. Prefer locale-neutral canonical URLs and let Steam's own localization handle the rest.
Trailing characters are the most common self-inflicted wound. A URL pasted with a trailing period, a closing parenthesis, or a space becomes invalid because the parser includes that character. Check the rendered store page, not just the backend field, because the backend may accept a string the renderer later mangles.
One counterintuitive detail: a link that appears correctly in the Steamworks editor preview can still fail on the live store page. The editor preview and the store renderer use different parsing passes. Always verify on a staged or unpublished store page before launch.
Timeline: when each link surface goes live
| Stage | Timing | What becomes visible |
|---|---|---|
| Backend field entry | At any time pre-launch | Editor preview only |
| Store page review | Typically days before launch | Store page pending state |
| Store page publish | At launch | Website field and community link |
| Community hub activation | At or after launch | Forums and discussions |
| Steam Guide publication | Any time after hub exists | Guide indexed in hub |
| External guide rendering | After store publish | Subject to whitelist at render |
| Post-launch edits | Any time | Changes re-enter review |
The key insight: community surfaces such as forums and Steam Guides generally require the product to exist and the hub to be active, so you cannot fully populate them weeks before launch. Build the website field and description links first, then add community links during the launch window.
Misconceptions and red-flag warnings
The biggest misconception is that the website field accepts a list. It does not. It holds one URL, and developers who paste two URLs separated by a space get a broken link or a rejected field.
The second misconception is that any https:// URL will render. The protocol is necessary but not sufficient. The domain whitelist decides whether the link becomes clickable, and shorteners and unknown domains are routinely stripped.
Pasting a bare domain without https:// and assuming Steam will fix it. Using a URL shortener for a store page link, which is likely to be blocked or stripped. Adding tracking parameters that push a URL past the field's character limit. Linking to an external forum as a substitute for enabling the native Steam hub discussions. Assuming the editor preview matches the live store renderer. Leaving a trailing period or parenthesis attached to a pasted URL.
Each of these produces the same user-visible result: a link that looks fine to you and does nothing for the player.
Practical actions: a field-by-field checklist
Start with canonicalization. Take every destination URL and reduce it to its shortest stable form with the https:// prefix and no tracking parameters. Test each one in a private browser window to confirm it resolves without a redirect chain.
Map each destination to the right surface. Put your product website in the store page website field. Enable native hub discussions for forums. Publish native Steam Guides for your online guide content. Reserve external URLs for supplements, and only after confirming the domain clears the whitelist.
Verify in two places. Check the backend field preview, then check a staged or unpublished store page render. The second check is the one that predicts what players see.
Set a pre-launch deadline. Populate the website field and description links at least several days before launch so they clear store review. Add community and guide links during the launch window once the hub is active.
Audit quarterly. Domains lose whitelist status, redirects change, and guides get restructured. Re-check every external link on a schedule, and replace anything that no longer resolves cleanly.
Limitations: what this method cannot guarantee
Steam does not publish its domain whitelist, its exact field character limits, or its render-time parsing rules. Any specific character count or domain list in this article reflects observed behavior and structural limits, not a published specification, so verify in your own backend before relying on a number. Whitelist membership can change without notice, which means an external link that works today can stop rendering later.
Native Steam surfaces are more durable than external URLs, but they constrain you to Steam's formatting and indexing. If your guide must live on your own documentation site, you accept whitelist risk. If it can live as a Steam Guide, you trade control for reliability.
Finally, no link strategy fixes a broken destination. A perfectly formatted https:// URL to a 404 page fails the player just as completely as a stripped link. Validate the destination content, not just the string.