Anyone looking after twelve websites rarely fails at the analysis and almost always at the organisation. This article shows how to structure ongoing SEO work in a team — one project feed instead of five filing systems, clear access levels, a flat tag system, reports not reinvented every month.
One website needs remarkably little tooling: a spreadsheet for the keywords, a browser tab with Search Console, a folder of screenshots. The break comes between the sixth and the tenth site — rarely as an insight, more often as a feeling: you no longer know what happened this week on which project.
This is where the new Semalt Panel comes in — less an analysis tool, of which there are plenty, than a workspace for people responsible for several websites at once: agencies, franchise head offices, companies with multiple brands or country domains, freelancers with a grown client base.
Why a portfolio fails differently from a single project
A single SEO project usually fails on substance: wrong keywords, weak content, technical problems, too little patience. A portfolio fails because information falls apart.
Campaign updates arrive by email. Backlink evidence sits in a spreadsheet whose column logic only its author understands. Client queries land in the project lead's inbox, the reports in a downloads folder, the to-dos in a task tool with no data connection at all. Each makes sense alone; together they turn "what happened on client X in July?" into half an hour of reconstruction.
The figures are an illustrative calculation, not a measurement: twelve clients, twelve months, half an hour per occasion. Roughly one working week a year spent finding things you produced yourself.
The consequence is unspectacular: events belong where the project lives, in the order they happened — in one stream, not five systems.
The My SEO Stream: one stream instead of five filing places
The My SEO Stream is where everything that would otherwise scatter comes together per project. It looks like a chat — except people are not the only ones writing.
The project feed as a living record
For teams that no longer want to reconstruct what was decided three months ago.
- Answers from the AI assistant. Grounded in actual project data, not general knowledge.
- Automatically generated reports. They sit at their point in the timeline instead of vanishing into an inbox.
- Newly placed backlinks. With domain rating and traffic of the donor domain — evidence with context, not a list entry.
- To-dos from the work in progress. They stay in the conversation where they arose.
- Campaign news. Status changes of the running automation, in order.
The practical effect: the project history need not be maintained, it emerges from the work. Asked in October why clicks dropped in June, you scroll back and see what stood there — the answer, the report, the links placed, the decision that followed.
Filters, to-do states and full-text search
A chronological stream has one drawback: after a few months it is long. Three remedies help, needed with differing frequency.
- Filters: All, Links, Files, To-do. The link filter answers "what did you build this month?" in one click, with domain rating and traffic. The file filter pulls every report and upload to the top.
- To-do states: active, snoozed, dismissed. Sparingly defined, and that is their strength. A portfolio consists largely of tasks that are right but not right now.
- Full-text search across all messages. The safety net: you need not know when something was discussed, only what it was about.
The "snoozed" state deserves a defence: the relaunch waiting on next quarter's budget, the content gap closed only after the season. With just "open" and "done" you get an overflowing list or a guilty conscience.
Full-text search returns not only the hit but its surroundings: you land at the right point and see what was going on around it — a combination of find and context a spreadsheet cannot deliver by design.
The assistant that actually reads the project data
The difference between the assistant in the Stream and a general language model in a browser tab is one of kind, not degree: a chatbot knows nothing about your project, a data-bound assistant reads it.
Ask a general model why clicks on a shop's category pages have fallen and you get plausible causes — not wrong, merely right independently of what happened, and therefore worthless operationally.
First decide which data is needed
Before every answer, a preliminary step selects the matching data blocks — sometimes none at all.
- Four data sources are available. Search Console data, SERP data, campaign data and custom blocks.
- Zero to three of them get loaded. The router model picks by relevance per question instead of tabling everything.
- Answers arrive as token streaming. After a second or two you see where the answer is heading, and can stop it.
- The history holds up to 20 messages. Follow-up questions work without repeating the context.
The zero is not an edge case but deliberate. "How do I explain the difference between impressions and clicks?" needs no project data and answers faster; "which keywords lost position over the past 28 days?" loads the matching blocks. The assistant also takes keyword and URL lists in batches.
The 20 messages are a deliberate limit too: generous for a working session, not a project memory spanning months. That is what the stream and its full-text search are for — worth knowing, or you will wonder why a follow-up after six weeks goes nowhere.
Multi-tenancy: who in the team may see what
As soon as more than one person is involved, access becomes a topic. The usual makeshift is a shared password — awkward when someone leaves, worse when you must justify under data protection law who accesses which data. In the Semalt working environment this is solved at several levels.
Linked Google account groups
Several Google accounts can be joined into groups — the normal case in agencies, where client websites are verified in separate accounts.
- No switching between accounts
- Verifications stay with the client
Sharing individual websites
A site can be shared with another registered email address. The emphasis is on individual.
- The client sees their website, not the portfolio
- Neighbouring clients stay invisible
Revoking existing access
Mentioned least often, needed most often. Access rights grow quietly.
- The intern from the summer before last
- The client's former head of marketing
The review rhythm
An overview you go through quarterly beats any policy nobody reads.
- Grant access with a notional expiry date
- Log the revocation as a to-do straight away
In practice: whoever shares a site for a pitch sets a to-do to revoke it afterwards. Ten seconds instead of an embarrassing discovery a year later.
Site tags: the global filter across the whole portfolio
In the panel, site tags are a global filter across every dashboard — not a label confined to one list but a selection carrying through the whole interface: filter to one client and every view speaks only about that client's websites. What you tag by is therefore an architectural decision. Four axes have proven themselves.
By client
Obvious as soon as a client has more than one domain.
- Main shop, outlet domain, brand magazine
- Three websites, one contact person
By country or language
For companies running .at, .de and .ch — and anyone assessing Austria separately.
- An answer to "how is Austria doing?"
- No distortion from the larger neighbouring market
By priority
Which projects need weekly attention, which monthly.
- Saves the most time in portfolio review
- The decision is made once, not every Monday
By contract status
Running, in notice, trial, paused. Commercial-sounding, but it governs effort.
- Trials need early results
- Paused projects need no weekly routine
Why a flat system works better than a deep one
The most common design mistake is the deep hierarchy: client-mueller, then client-mueller-shop, then client-mueller-shop-at — six months later 40 tags exist, 30 applying to exactly one website. A tag that filters a single object is not a tag, it is that object's name.
Flat works better because tags combine: a few separated axes, one value from each per website. Four axes with a handful of values each produce many useful combinations without a tree to memorise.
cl-, cty-, prio-, status-); an upper limit — more than 20 to 25 tags is a signal to tidy up; and fixed ownership: everyone may use tags, only one person creates them.Which setup suits which role
Not every constellation needs the same setup: a sole trader with three websites copying a 60-site agency's system ends up doing nothing but administration. The overview below is a starting point, not a prescription.
| Role / portfolio size | Tag system | Sharing | Account groups | Report format |
|---|---|---|---|---|
| Single business, 1 website | Not needed | None, or one for the bookkeeper | One account is enough | PDF, monthly |
| Freelancer with side projects, 2–4 sites | One axis: priority | Rare, project-specific | One account, possibly two linked | PDF for yourself, CSV on demand |
| Small agency, 8–15 client websites | Two axes: client + priority | One site shared per client | Group across all client accounts | Branded PDF per client |
| Company with country markets, 5–20 domains | Two axes: country + brand | One site per country manager | Group across the country accounts | PDF for management, CSV for the markets |
| Franchise / branch network, 20–60 sites | Three axes: region + status + priority | Each franchisee gets their own site | Central group, branch accounts linked | PDF per branch, CSV for head office |
| Larger agency, 60+ sites | Four axes, strictly maintained, fixed ownership | Role-based, reviewed quarterly | Several groups by team | CSV/JSON into your own analysis, PDF to clients |
The rows read cumulatively: each level takes on the one above and adds an axis or a review routine. If you grow, you add — you do not rebuild.
Reporting, export and visualisation
Reports are where portfolio organisation pays off or takes its revenge. Gather the numbers afresh each month and you lose a working day; have them structured and you lose an hour. The export limits are stated clearly.
| Format | Upper limit | How it is produced | Typical use |
|---|---|---|---|
| CSV | 10,000 rows | Direct export | Your own analysis, spreadsheets |
| JSON | 10,000 rows | Direct export | Further processing, your own dashboard |
| 250 rows | Rendered server-side | Monthly report to clients and management | |
| Table view | 50–200 rows per page | Filterable and sortable | Daily work in the panel |
The asymmetry between 10,000 and 250 rows is jarring at first, sensible on closer inspection. A PDF gets read; 3,000 table rows get filed away. The 250-row limit forces the question of which 250 rows tell the month's story — and that question is the consultancy work.
The configurable report builder decides which components a report contains. Fix one configuration per client type and stick to it: a consistent structure allows comparison with the previous month, while a report that looks different every time seems more elaborate and says less. Set up templates and branding once in the Semalt dashboard and they are set for every client.
Time series
They answer the question of direction and are often the only thing discussed.
Metric cards
The current state in one line. In a portfolio review they replace opening twelve detail views.
Sparklines
A miniature curve beside a table row answers "stable or moving?" without a click.
Heatmaps for countries and devices
They expose imbalances that vanish in averages — weak mobile performance in one market, say.
These formats are deliberately conventional — nobody needs them explained. Because background workers keep the data synchronised, the views are current without a refresh: you open the page and it is right.
A week at a small Vienna agency
The sequence below is a constructed example, not a case study: a three-person Vienna agency with twelve client websites — seven Austrian SMEs, two companies with a .de domain, an association, a shop, a law firm.
Monday morning: the portfolio review
The week begins not with twelve projects but with a filter. The tag prio-high cuts the portfolio to four websites; for those, metric cards and 28-day time series are reviewed, then the stream is set to All.
Then the filter switches to prio-standard. The remaining eight are skimmed through the metric cards; anything unusual goes into the relevant Stream as a to-do. The review takes roughly 45 minutes, because the prioritisation sits in the tags rather than being made every Monday.
Tuesday to Thursday: the working week
Daily life consists of requests. A client believes their visibility has dropped. Instead of assembling screenshots, the question goes into the project's Stream; the router model loads the matching blocks, a follow-up sharpens the answer. The chain stays in the record.
To-dos accumulate alongside. An item for the law firm is snoozed, because legal will only sign off on text changes next quarter; one on the shop is dismissed, because a relaunch resolved the problem. Both decisions stay documented — more useful at the next renewal than any later recollection.
End of month: the report
On the last working day the reports are generated; with the configuration per client type fixed, the structure matches the previous month. The SMEs receive a branded PDF, the shop additionally a CSV export, the two .de clients reports split by country — the country tags deliver that without rework.
The demanding part is not the generation but the accompanying text: three to five sentences per client on what the numbers mean and what is planned next month. Those sentences are written by a person.
Where automation ends and consultancy begins
It would be dishonest to sell this setup as a solution to the actual work. It solves the organisational layer — filing, findability, access, repeatability — not the decisions.
prio-high holds no truth about importance, only an assessment that goes stale if nobody reviews it. Causality: the assistant shows that clicks fell and which keywords are affected — the why follows from context no system has, a price increase in May, say. Goal-setting: whether you optimise for reach, enquiries or margin is a business decision; a tool can make it measurable, not make it. Client communication: the conversation about a disappointing quarter remains human work.The honest benefit is the shift: if the organisational layer holds, more time is left for the decision layer. Less spectacular than optimisation that runs itself, but verifiable. The modules are described in the overview of Semalt features; for the technical groundwork the road still runs through technical SEO.
Frequently asked questions
From how many websites onwards is a dedicated organisational layer worth it?
There is no hard threshold, but the break usually sits between six and ten projects. Below that your own overview suffices; above it, reconstruction begins. If you expect to grow, introduce the first tag axis early — laying it over 30 websites later is harder than over eight.
Does a client given access to one website also see the other projects?
No. Sharing happens per website, to a registered email address. The recipient sees the shared site, not the portfolio and not the tag structure. Existing shares can be inspected and revoked, which you should do quarterly.
Why does the assistant sometimes answer without project data?
Because the router model decides per question which blocks are relevant, and it can load zero. For general questions of understanding that is intended and faster. If you expect a data-based answer, phrase it concretely — period, website, metric — and the selection works more reliably.
What happens to older conversations if the history only holds 20 messages?
The messages do not disappear, they are simply no longer part of the immediate conversation context. They remain in the Stream in order and are findable through full-text search. After several weeks, quote the relevant passage rather than rely on short-term memory.
Is a PDF with 250 rows enough for a monthly report?
For client reports, as a rule yes: a monthly report lives on selection anyway. If you need the complete data — for your own analysis or a data warehouse — export CSV or JSON with up to 10,000 rows and file both together.
The mistake when building a portfolio structure is always the same: too much at once. A sequence works better — add the websites and link the accounts, introduce one tag axis, run one project entirely in the Stream, fix one report configuration, then tidy the sharing rules.
The most practical first step is small: create two or three websites and work exclusively in the panel for a month. If you want to try it, set up access to the Semalt Panel and test your system on a manageable slice of the portfolio.
Whether the effort paid off comes down to one question: how long does it take to answer "what happened on this client last quarter?" Under two minutes, and the organisational layer has done its job. The rest is your work again.