If you have ever managed more than three HubSpot portals for agency clients, you already know the drill. Log in. Click around. Find the page you need. Make the edit. Log out. Log in to the next one. Repeat until your afternoon disappears.
I spent the better part of 2024 building internal tooling to make this less painful. Browser profiles for each client. A Tampermonkey script that auto-detected which portal I was in and color-coded the nav bar so I would stop accidentally editing the wrong site. A shared Notion doc where our team tracked which portals needed what updates each week.
It worked, kind of. But it was duct tape on a structural problem.
The Core Issue: HubSpot Portals Are Islands
HubSpot was not designed for people who need to operate across multiple portals simultaneously. Every portal is its own universe. Its own login context. Its own set of pages, blog posts, redirects, and settings. There is no native way to view content across portals, compare settings between them, or perform the same action in multiple portals without doing it manually each time.
For a single brand, this is fine. For an agency running content operations across a dozen clients, it creates a workflow that looks more like a context-switching penalty than a content management system.
Here is what the actual day looks like. You get a Slack message from a client asking you to update meta descriptions across 40 blog posts. You log into their portal. You open the first post. You click into settings. You change the meta description. You save. You go back to the list. You open the next one. Forty times.
Then another client pings you with the same request. New portal. Same tedious process. Different set of 40 posts.
And that is just metadata. When a client asks you to do a find-and-replace across their blog (say, swapping out an old product name for a new one), you are looking at the same page-by-page grind. There is no built-in find-and-replace for HubSpot CMS content. The Ideas forum has had this request open for years. The community workaround is either "do it manually" or "use the API."
The Math Nobody Talks About
Let us say you manage 10 client portals. Each client has a website with somewhere between 50 and 500 pages. Every quarter, you run a hygiene pass: checking metadata, fixing broken redirects, updating alt text, cleaning up outdated content.
If each portal takes you four hours of manual editing per quarter (and that is conservative for a 200-plus page site), you are looking at 40 hours. That is a full work week, every quarter, just on maintenance.
Now multiply that by the number of people on your team who touch CMS content. The hours compound fast.
The frustrating part is not the work itself. It is the fact that you are doing the same type of work, in the same type of interface, across portals that do not talk to each other.
What I Actually Needed
When I stepped back and looked at what I was really trying to solve, it came down to three things.
First, I needed a way to see and edit content across multiple portals without logging in and out. Not a dashboard that shows me analytics. An actual editing interface where I could make changes.
Second, I needed bulk operations. Not the "select five pages and archive them" kind that HubSpot offers natively. Real bulk editing. Change 200 meta descriptions at once. Find and replace a URL across every blog post on a client site. Update alt text in a single pass.
Third, I needed an audit trail. When you are making changes across client sites at scale, you need to know what changed, when it changed, and who changed it. HubSpot does not give you that level of visibility for CMS content changes.
The Tooling Gap
I looked at the HubSpot API. You can absolutely build something that hits the CMS endpoints and modifies content programmatically. I did this for a while. But writing and maintaining custom scripts for every type of bulk operation, across every client portal, is its own full-time job. Every time HubSpot updates their API, something breaks. Every time a client has a unique content structure, you need a new script variant.
I also looked at the HubSpot Ideas forum. The request for bulk metadata editing has been open for years. Hundreds of upvotes. Comments from people managing 500-plus page sites saying they are spending weeks on tasks that should take minutes. HubSpot has not shipped a native solution.
The community responses are revealing. One agency user wrote that they can export all their titles and descriptions instantly but importing them back is "one huge grind for the team." Another said it could "save weeks of internal work for mid to large sites." These are not edge cases. These are the daily reality for anyone managing client websites at scale.
This is the gap where tools like Smuves exist. It is a bulk CMS editor built specifically for HubSpot that lets you connect multiple portals from a single dashboard, edit content in bulk, and push changes back with activity logging. The kind of thing I was trying to duct-tape together with scripts and browser profiles.
Their bulk editing guide walks through the actual workflow: export content to Google Sheets, make your changes in a familiar spreadsheet environment, and push updates back to HubSpot. For agencies, the multi-portal piece means you do not need to juggle logins or maintain separate editing processes for each client.
What I Learned From Building (and Abandoning) My Own Solution
The biggest lesson was not technical. It was operational.
Custom tooling only makes sense when the problem is unique to you. The multi-portal editing problem is not unique. Every HubSpot agency deals with it. The fact that so many agencies build their own workarounds (browser profiles, API scripts, elaborate Notion trackers) tells you that the native tooling has a blind spot.
The second lesson was about context switching. Every time you log into a different portal, your brain has to re-orient. Which client is this? What are their brand guidelines? Where did we leave off last time? That cognitive overhead is invisible in time tracking but very real in output quality.
The third lesson was about risk. When you are manually editing pages one at a time across multiple portals, mistakes happen. You paste the wrong meta description. You update the wrong redirect. You accidentally publish a draft. Without proper logging, you might not catch it until a client calls you.
For Other Agency Devs
If you are still in the "build it yourself" phase, here is my honest take. Spend the time on tooling that is specific to your agency's unique value proposition. The CMS bulk editing problem has been solved by people who focus on it full time. Your energy is better spent on the things that actually differentiate your agency.
And if you are an agency ops person who keeps hearing "we will just use the API" from your dev team, push back. Ask them how many hours they spent last quarter maintaining those scripts versus the hours they could have spent on client-facing work. The answer is usually sobering.
The portal-switching tax is real. Most agencies just never put a number on it.
Top comments (0)