Go links (also written golinks, go/links, or “internal short links”) are short, memorable keyword shortcuts that send your team to a specific URL. Instead of hunting for a dashboard or a doc, a teammate types something like go/payroll or b/oncall in the browser and lands on the right page instantly. One keyword, one destination, the whole team in the same place.
The pattern was born inside Google, where employees navigate to internal tools by typing go/ followed by a name — go/cafe, go/payroll, go/oncall. It worked so well that engineers who left Google kept rebuilding it at their next company, and a small category of tools grew up around it. Today “go links” is the generic term for any team short-link system that turns a forgettable URL into a name everyone can remember.
What is a go link?
A go link has two parts: a prefix and a keyword. The prefix is the namespace your team agrees on — classically go/, but plenty of teams use a single letter like b/ to save keystrokes. The keyword is the human-readable name you give a destination. Put them together and you get a shortcut anyone can type from memory:
go/wiki→ your team’s knowledge basego/deploy→ the deploy dashboardgo/oncall→ the current on-call schedulego/roadmap→ the live product roadmap
The point is recall, not brevity. A go link is not a URL shortener like Bitly — those produce random strings (bit.ly/3xKp9) meant to be clicked, not typed. A go link is the opposite: a name a human chooses on purpose so it can be typed from muscle memory, shared out loud in a meeting, and pasted into a runbook without anyone needing to look it up. BookSlash uses the b/ prefix for exactly this reason — b/slugs are go links you type in the address bar.
How do go links work?
Every go link does the same job — catch the shortcut you typed and redirect you to the saved URL — but there are three common ways to make that happen. The differences matter mostly for how hard the system is to set up and who can use it.
1. DNS-based resolution
The original Google approach. An admin configures your internal network so that go/ resolves to a small redirect server on your corporate network. When you type go/wiki, the request hits that server, which looks up the keyword and 302-redirects you to the real URL. It is elegant and prefix-free for the user, but it needs IT to own DNS, only works on devices on the network or VPN, and breaks for contractors, mobile, and anyone working off-network.
2. Browser-extension resolution
A browser extension watches the address bar and intercepts the prefix before the request leaves your machine. Type b/wiki and the extension rewrites it to the saved destination. No DNS, no network changes, no IT ticket — any teammate installs the extension in seconds and it works on their laptop wherever they are. This is how BookSlash resolves slugs, with a browser extension for Chrome, Firefox, Edge, Safari, and Brave, plus resolution from Raycast and Spotlight.
3. Custom short-domain resolution
For people who do not want an extension, the system also serves shortcuts from a real domain — for example b.your-co.com/wiki. The lookup happens at the edge and 30x-redirects to the destination. It works in any browser, on mobile, and inside any tool that opens a URL, at the cost of a couple of extra characters. Most teams combine the extension (fastest) with a custom domain (universal fallback).
Why teams use go links
Go links solve a small problem that compounds badly: links rot, and people forget where things live. The same URL gets pasted into a dozen Slack threads, bookmarked by half the team, and changed the week after onboarding. The cost is invisible until you add it up — every “hey, where’s the dashboard?” is a context switch for two people. Go links fix four things at once:
- Shared memory. The link belongs to the team, not to one person’s bookmarks bar. Everyone reaches
go/handbookthe same way. - Survives change. When the destination URL moves, you update the go link once and the shortcut everyone already knows keeps working.
- Faster recall. Typing a name you chose is faster than searching a wiki, scrolling browser history, or guessing a folder structure.
- Onboarding shortcut. “Memorise these ten slugs” replaces a week of learning where everything lives.
The teams that get the most out of go links tend to be the ones with a lot of internal destinations to keep straight. A few patterns we see constantly: engineering teams pin a slug per service for runbooks and dashboards; on-call rotations keep a single b/oncall for incident response; and people teams hand new hires a board of slugs on day one for onboarding.
Go links vs bookmarks vs a wiki
Go links are often confused with browser bookmarks or a team wiki, because all three are ways to “keep track of links.” They solve different problems. Bookmarks are personal recall; a wiki is where knowledge is written down; go links are how the whole teamreaches a destination in one keystroke.
| Capability | Browser bookmarks | Team wiki | Go links |
|---|---|---|---|
| Shared across the whole team | No — per device | Yes | Yes |
| One keystroke to the destination | Partial | No — search first | Yes |
| Survives a URL change | No | If someone edits it | Yes — update once |
| Works from the address bar | Partial | No | Yes |
| Roles, permissions, audit log | No | Usually | Yes (managed tools) |
In practice they are complements, not rivals. The wiki holds the long-form content; the go link is the fast path to it. Many of a team’s most-used wiki pages and bookmarks simply become go links — see how this plays out against Notion and Chrome bookmarks.
How to set up go links for your team
Whatever tool you choose, rolling out go links follows the same five steps. The whole thing takes an afternoon for a small team.
- Pick a resolution method. Self-hosting and DNS give you full control but need engineering time; a managed extension-based tool is live in minutes. Match the choice to how much ops you want to own.
- Choose a prefix.
go/is traditional;b/is shorter. Pick one and keep it consistent so muscle memory builds. - Seed the core links. Start with the ten destinations people ask for most — wiki, deploy dashboard, on-call, roadmap, design files, HR portal. Import existing links from a CSV or a bookmarks export rather than typing them by hand.
- Agree on a naming convention. Decide the shape up front (see below) so a new slug’s name is predictable instead of a guess.
- Roll it out. Pin the prefix in your team handbook, add the extension to onboarding, and ask people to create a slug the next time they paste a URL twice.
Go link naming conventions and best practices
A go-links system lives or dies on naming. If people can guess the slug for a destination without being told, adoption takes care of itself. A few conventions that hold up:
- Lowercase, no spaces.
b/design-system, notb/Design System. - Namespace by type, then thing.
b/runbook-checkout,b/dash-payments,b/adr-014— the prefix tells you what kind of page you’ll land on. - Prefer the obvious word. The slug should be the first thing someone would type. If two teams would guess differently, add both as aliases.
- Lock the high-value names.
b/handbookandb/oncallshould not be overwritable by accident — reserve them to admins. - Audit and prune. Review click analytics quarterly; retire dead slugs and fix the ones pointing at moved pages.
Common go links to start with
The fastest way to get a team hooked is to seed the destinations everyone already asks for. You do not need a hundred slugs on day one — a couple of dozen well-named ones cover most of the “where’s the link?” traffic. Here is a starter set, grouped by who reaches for them:
- Company-wide:
b/handbook,b/holidays,b/benefits,b/org(the org chart),b/allhands,b/brand. - Engineering:
b/deploy,b/status,b/oncall,b/runbook-checkout,b/dash-payments,b/adr(architecture decisions). - Design:
b/figma,b/tokens,b/icons,b/review(the current critique board). - Sales & customer success:
b/pricing,b/deck,b/crm,b/acme(a board per key account). - People & ops:
b/onboarding,b/expenses,b/timeoff,b/it(how to get help).
Notice the pattern: every slug is the first word someone would actually type. When a team outgrows flat names, the type-then-thing convention (b/runbook-checkout, b/dash-payments) scales to hundreds of links without anyone needing a directory. Package the most-used ones onto a shared board so a new hire’s first day is a single slug — see onboarding for the full pattern.
Go links, access control, and governance
A go link is, by design, a piece of shared infrastructure — which means that past a handful of people, who can create, edit, and see each slug starts to matter. A personal bookmark tool never has to answer these questions; a team go-links system does. The features that separate a hobby setup from something a company can rely on:
- Roles and permissions. Owner, Admin, Member, and Guest roles decide who can mint a slug, who can edit a high-traffic one, and who can only follow it. Without this, any teammate can quietly repoint
b/payrollat the wrong place. - Locked names. The handful of slugs everyone depends on —
b/handbook,b/oncall,b/status— should be reservable so they cannot be overwritten by accident. - Audit logs. A tamper-evident record of who created, edited, or deleted each slug, and when. This is what turns “the link broke” into a two-minute fix instead of a forensic exercise.
- Clean offboarding. When someone leaves, their slugs should transfer to the team, not vanish with their account. Workspace-owned links survive turnover; personal bookmarks do not.
- SSO and SCIM. For larger teams, single sign-on and automated provisioning keep access in lockstep with your identity provider.
This is the line between a free open-source script and a managed product. BookSlash builds roles, locked slugs, and audit logs into team workspaces, with SSO and SCIM on Enterprise — the details are on the security page.
Go links tools compared
Three tools own most of the go-links conversation. All three deliver the core wedge — memorable shortcuts to internal destinations — so the real choice is about hosting, who can set it up, and what (if anything) sits behind the link. Pricing below is each vendor’s current public pricing; always re-check their site, since prices drift.
GoLinks
The longest-running commercial go-links product, and the most polished take on the classic idea. It has a free tier for up to 20 users, with paid plans from $2/user/month (Basic) and $4/user/month (Pro); SSO/SCIM and advanced controls are on Enterprise. If you want a focused, hosted go-links tool and nothing more, it is a strong default. See the full breakdown on BookSlash vs GoLinks.
Trotto
The well-known open-source option. Trotto offers a managed plan (free up to 10 users, then $3/user/month for Team) and an open-source core you can self-host for free if you are happy to run the service, handle auth, and own uptime yourself. It is the right pick for teams who value open source and have the engineering time to operate it — more on BookSlash vs Trotto.
BookSlash
BookSlash is a modern take on the category: the same b/ go links, hosted and resolving at the edge in under 40ms, with a free tier for personal use and Pro at $5/user/month ($4 billed yearly). The difference is what sits behind the shortcut — every slug can resolve to a multi-tool canvas (kanban, embeds, notes, invoicing, sitemap audits), not just a redirect — plus role-based access, custom slug domains, and audit logs from Pro. It is the option for teams who want go links and a place for the work to live.
Getting started with go links
If you want to try the idea today, the fastest path is an extension-based tool: install it, import your existing links, and start typing. With BookSlash that means installing the browser extension, claiming the slugs your team asks for most, and sharing the b/ prefix in your handbook. It is free for personal use, so you can prove the pattern on your own links before rolling it out to the team. Explore go links for specific tools — from Slack to GitHub to Figma — or see exactly how slugs work end to end.