Three Agency Weeks, Three Workspace Removals: What Actually Happens in Ahrefs

It was 4:47 on a Tuesday afternoon when Dana, our senior link builder, leaned over my desk and said the words every agency team lead eventually hears: “Marcus’s contract ends Friday. Do we need to do anything about his access?” At almost the same moment, my phone buzzed with an email from a client ending their retainer after fourteen months, and somewhere in a Slack thread from earlier that morning, someone had asked why we had a workspace called “test test do not use.” Three removal problems, all landing in the same week, all living inside the same tool. That’s how this article came to exist. Rather than hand you a sterile checklist, I want to walk you through how each of those situations actually unfolded, because the mechanics of how to remove from ahrefs workspacew make far more sense when you see them attached to real people, real deadlines, and real messes.

Monday to Wednesday: The Contractor Whose Last Day Crept Up

Marcus had been with us for six months on a content contract. He wrote meta descriptions, cleaned up broken internal links, and spent most of his hours inside two shared workspaces: our main agency workspace and a workspace we’d built specifically for one large ecommerce client. When Dana flagged his departure, my first instinct was the lazy one — “He’s a contractor, he probably only has view access, it’ll sort itself out.” That instinct was wrong, and I’m glad we checked.

When I opened the shared workspace settings, I found Marcus listed as a member with a level of access that let him edit projects and reports, not just look at them. Nobody had upgraded him deliberately; it had simply happened months earlier when we were rushing to get him into a sprint and someone clicked the wrong option. That’s the quiet danger of shared workspaces: access accumulates. People get added for one project and stay added for ten.

Removing him was straightforward once I was actually in the right screen. Inside the workspace, the member list showed everyone with access, and next to Marcus’s name there was a control to remove him from that workspace. I removed him from the client workspace first, then from the main agency workspace. Two clicks, two confirmations, done. The part that took longer was the audit — checking whether he appeared anywhere else. He didn’t, but the check itself was worth doing, because a half-removed contractor is worse than a fully-removed one. If he’d retained access to the client workspace but lost access to the agency one, he might have assumed he’d been fully removed and stopped thinking about it, while still technically holding a door open.

The other thing I learned: removing someone from a workspace isn’t the same as removing them from your life. Their historical activity, reports they generated, and projects they touched don’t vanish. That’s actually good. You want the audit trail. You just don’t want the person.

What this teaches: Treat every contractor offboarding as a two-step process — remove the person, then verify the removal everywhere. Access levels drift upward over time, so never assume a departing collaborator only had limited permissions. Open the member list, read it, and remove deliberately rather than hopefully.

Wednesday to Thursday: The Client Who Ended the Retainer

By Wednesday morning, the retainer email had been forwarded around the leadership team and the decision was made: we’d finish the month, hand over assets, and close out the relationship on good terms. The account had its own shared workspace, built around a year of keyword research, backlink audits, and content calendars. The question wasn’t whether to remove the client — it was what “remove” should even mean in this context.

Here’s where agency teams get sloppy. There are two different actions people conflate: removing a client’s team members from your workspace, and removing the workspace itself. They solve different problems. If the client is leaving but you might work together again, or if you need the historical data for your own case studies, you remove their people and keep the workspace. If the relationship is fully over and the data belongs to them, you hand over what they need and then decide whether the workspace has any future purpose at all.

We did the first option. I went into the client’s shared workspace, found each of their team members in the member list, and removed them one by one. Two of them had admin-level access — a leftover from a period when they were deeply involved in approving deliverables. Removing an admin feels weightier than removing a viewer, but the action is the same: select the member, remove them from the workspace, confirm. The workspace itself stayed, now populated only by our internal team, quietly becoming an archive.

The subtle part was communication. We told the client exactly what we were doing and when. “On Friday we’ll remove your team’s access to the shared workspace; if you need anything exported before then, tell us now.” That message prevented the awkward follow-up email three weeks later asking why someone couldn’t log in. Removal without notice reads as ghosting. Removal with notice reads as professionalism.

What this teaches: Separate the person from the workspace. Removing members preserves your data and your options; removing the workspace is a bigger, less reversible decision. Always give departing collaborators a clear deadline before you pull access, and export anything they might need while you still can.

Thursday to Friday: The Workspace Nobody Remembers Creating

And then there was “test test do not use.”

I’d been ignoring it for months. It appeared in the workspace switcher every time I logged in, a small monument to someone’s forgotten experiment. On Thursday afternoon, with the contractor situation resolved and the client offboarding in motion, I finally decided to deal with it. The problem: I didn’t know who created it, what was inside it, or whether anything in it mattered.

So I opened it. Inside were three projects, all from an old pitch we’d lost eighteen months ago, plus a handful of saved reports nobody had touched since. No active members except me, because the original creator had already left the agency. It was digital sediment — harmless on its own, but the kind of thing that multiplies until your workspace switcher becomes a graveyard.

Cleaning it up meant two decisions. First, was there anything worth keeping? I exported one report that had useful competitive data, dropped it into our main workspace, and let the rest go. Second, how do you actually remove a workspace you no longer want? In Ahrefs, this lives in the workspace settings, and it’s worth knowing that removing a workspace is a more consequential action than removing a member — it affects everyone who has access, not just you. Since I was the only remaining member, the decision was mine to make cleanly. If there had been other active members, I would have needed to coordinate first, because deleting a shared workspace out from under a colleague is a genuinely bad look.

After it was gone, the switcher felt lighter. That sounds trivial, but it isn’t. Every stray workspace is a small cognitive tax — a thing you have to remember to ignore. Removing it returned a tiny bit of clarity to every future login.

What this teaches: Audit your workspace list the way you’d audit a closet. Open the mystery workspaces, check for members, salvage anything valuable, and remove what’s genuinely dead. And before removing a workspace rather than a member, confirm you’re the only person who’ll be affected — or get everyone’s agreement first.

Preventing Next Month’s Removal Headache

By Friday evening, all three problems were solved, and I noticed something uncomfortable: none of them were hard. The difficulty was entirely in the delay. Marcus’s access lingered because nobody owned offboarding. The client’s members lingered because we’d never defined what happens when a retainer ends. The test workspace lingered because ignoring it was easier than investigating it.

So we changed a few habits. Now, every contractor’s start date comes with a calendar reminder on their end date — a five-minute task to review and remove their workspace access. Every client offboarding checklist includes a line item for member removal with a communicated deadline. And once a quarter, someone on the team opens the workspace switcher, looks at every name in it, and asks the same simple question: does this still need to exist, and does everyone in it still need to be here?

None of this is glamorous. It’s the unglamorous plumbing of running an agency in a shared tool. But the week taught me that removal isn’t really about deletion — it’s about attention. The mechanics of removing a member or a workspace are simple and quick. The hard part is noticing, in time, that something needs removing at all. Get that part right, and the clicks take care of themselves.