Setup & IT rollout
go/ links resolve through theChrome extension — one click, nothing for IT to do, or force-installed across a fleet. Below: installing it, rolling it out, and how to share links with people who don't have it yet.
Recommended: the browser extension
Best experienceWe recommend the extension for ~everyone. It interceptshttp(s)://go/<slug> right in the browser and redirects to slashgo.io/go/<slug> — the request never even hits the network, so there's no DNS to configure and no rough edges. It also adds the Google-search fallback and the go <slug> omnibox keyword.
Edge runs the Chrome build — install it from the Chrome Web Store. There's no Safari version yet. The fleet rollout below is Chrome-only for now; the Firefox build on AMO predates the managed-policy support it needs.
Optional polish: add 127.0.0.1 go to your hosts file sogo/<slug> resolves instantly instead of bouncing through a Google search. The extension catches it before it leaves your machine, so the IP is just a placeholder — 127.0.0.1 is the standard pick.
Sharing links with people who aren't set up
go/<slug> only resolves on machines that have the extension installed. Paste one into a channel and anyone without it gets a browser error, not your link — which is the usual reason a rollout stalls.
So when you're announcing SlashGo, or sending a link to someone who may not be set up, use a normal web address instead. Both of these open for anyone, on any browser, phones included:
slashgo.io/start/<your-company> # explains go/ links, then signs them in slashgo.io/go/<slug> # goes straight to one link
Your company's start link is under Settings → Organization, ready to copy. It shows your company name, explains what go/ links are for someone who's never seen one, and sends them on to whatever they were trying to open.
Why not just make go/ work everywhere?
A bare, dotless hostname like go can't hold a public TLS certificate, so HTTPS-first browsers refuse it before any redirect can happen. That's inherent to every go/ system, and it's exactly what the extension sidesteps by never letting the request reach the network.
MDM deployment
Rolling out at scale is two things: force-install the extension, then set your organization slug so teammates who open a go/ link before signing in see a page naming your company.
1. Force-install, by ID
Add the extension by ID, not from the store listing (per-platform notes below). A hand-installed extension shows as Locally added and can't receive policy, so step 2 won't work.
echkofajdnmialdcbhgdoabbpjcadbdm2. Set your organization slug
Paste this into Policy for extensions, with your own slug. Your slug and a ready-to-paste copy of this are under Settings → Organization in the app.
{ "orgSlug": { "Value": "your-slug" } }The field only appears for an extension added by ID, running 1.4.1 or later — the first version that can accept policy.
3. Check it worked
Sign out first — the company page only shows to signed-out visitors, so signed in you'll just be forwarded to your dashboard. Then openslashgo.io/start/<your-slug>. Policy reaches a browser in about three hours (immediately on restart); extension updates take about five. On a managed machine, chrome://policy →Reload policies should list orgSlug — if it doesn't, the problem is policy delivery rather than SlashGo.
Per-platform notes for the force-install itself:
Google Admin
Force-install under Devices → Chrome → Apps & extensions; push hosts via Chrome Browser Cloud Management or a managed-OS profile.
Extension policy docsJamf (macOS)
Push the extension as a managed app; deliver the hosts entry with a Files & Processes payload or config profile.
Jamf docsMicrosoft Intune
Force-install via Chrome ADMX templates; append the go entry to hosts with a PowerShell script or profile.
Why the extension asks for a host permission
The extension requests host_permissions: ["https://slashgo.io/*"]for one reason: to redirect a go/<slug> request (and the Google-search fallback) to slashgo.io/go/<slug>. It does not read page content, and it never sends your browsing anywhere except the go/ resolution you triggered. The destination URL is resolved by slashgo.io, where it's stored AES-256 encrypted at rest.
Troubleshooting: “go/ doesn't resolve”
That's the fallback working — the extension should then catch the search and redirect. Confirm the extension is installed and enabled and that you're signed in. To skip the bounce entirely, add the 127.0.0.1 go hosts entry.
That's the dotless-HTTPS rough edge: the browser tried https://go first, which can't have a certificate. Use http://go explicitly, or — recommended — use Chrome with the extension, which avoids the network entirely.
They likely haven't installed the extension. Send them to this page, or roll it out via MDM so it's automatic.
A Chrome update can disable sideloaded/unmanaged extensions. Re-enable it at chrome://extensions, or force-install via MDM to prevent it.
Two causes, both silent. Either the extension was added by hand rather than by ID — an entry showing “Locally added” can't carry policy, so remove it and re-add by ID — or the installed version is older than 1.4.1, the first version that can accept policy.
Usually it's the tester or the clock, not the config. Sign out first — the company page only shows to signed-out visitors, so signed in you'll just be forwarded to your dashboard. Then allow about three hours for policy to reach a browser (restarting Chrome forces it), and confirm delivery at chrome://policy → Reload policies, where orgSlug should be listed.