Tidy Up Multiple WordPress Sites in MyKinsta With a Simple System
A practical, step-by-step playbook for agencies and developers who manage growing WordPress portfolios in MyKinsta, covering naming, labels, roles, bulk actions, and the API.
Running a dozen WordPress installs inside the MyKinsta dashboard is comfortable. Running thirty or more without a system is where things start to fall apart. Sites pile up under default install slugs, teammates search the wrong project, and routine maintenance quietly skips the wrong account. The good news is that MyKinsta already contains everything needed to bring order to a crowded portfolio. This guide walks through a practical method to organize multiple WordPress sites in MyKinsta without rebuilding anything from scratch.
Key Takeaways
- A consistent naming format is the foundation for search, filters, bulk actions, and API queries across every site.
- Site labels turn a flat list into one-click views, though MyKinsta filters by a single label at a time.
- Layering client, site type, and lifecycle status gives agencies a reliable way to segment work.
- User roles separate client accounts from internal teammates without restricting necessary access.
- The Kinsta API becomes valuable once labels and naming alone cannot answer the operational question.
Why a busy dashboard is not a system
Most accounts that have grown organically still carry the original install slugs. The result is a Sites list that reads like a column of near-identical names. Several team members usually hold company-wide access, so any client query turns into a hunt through similar installs. Nothing is broken. The dashboard simply lacks the structure needed to manage work at scale. Smaller teams often compensate by keeping context in one person's head, but that informal approach stops working once the portfolio crosses roughly thirty projects across multiple departments and environments.
Start with a naming convention every site can share
Naming is the keystone because search, filtering, bulk selection, and the API's site_display_name field all read from it. Inconsistent names limit every feature built on top. SSH and SFTP usernames, MySQL database credentials, and public server folder paths do not change when the display name changes, which means deployment scripts keep working.
To rename a site, open the Sites list and click the kebab (three-dot) icon next to the entry, then choose Rename site. The same option lives under Sites > sitename > Info. Company Owners, Administrators, Developers, and Site Administrators can all perform this action.
A reliable format pairs a tag with a short description, for example tag:value. The file includes visits, bandwidth, disk usage, PHP version, and data center for each entry, which makes it easy to draft new names in a spreadsheet and apply them in passes.
Build a label taxonomy you can filter in one click
MyKinsta's site labels have been available for a while, and applying them with a plan is far more effective than tagging reactively. On the Sites list, select the sites that should share a label, open Actions, and pick Change labels. In the dialog, tick existing entries or click Add new label, type the name, and select it. Confirming the dialog writes the label to every selected site at once. To keep the vocabulary tidy, open Company settings > Site Labels and edit or remove entries there. Once a group of sites carries the same label, the label filter on the Sites list narrows the view to that group alone. To learn how labels fit alongside other file-level work, see our guide on how to access and edit WordPress files in myKinsta.
One important limitation is worth noting: MyKinsta filters by a single label at a time. Showing every site tagged for commerce or every site marked active is easy, but combining the two requires a different tool. That is where the Kinsta API comes in.
Layer two parameters for sharper segmentation
Many accounts stop at the client name. Adding a second axis turns labels into a usable operational tool:
- Client or ownership records who the site belongs to, so a single filter pulls every project for one customer.
- Site purpose records what the site does, which helps when a release or patch only affects certain builds.
With both axes in place, most operational questions can be answered with one filter. If you are still deciding how each new project should be set up, our walkthrough on how to install WordPress the right way pairs well with this labeling step.
Add an optional lifecycle status for routine work
A third parameter, applied as a status label, turns the Sites list into a live record of work in progress. Four values cover most agency flows:
| Status Label | Meaning | Routine Treatment |
|---|---|---|
| new-build | Unpublished site still in development | Exclude from maintenance passes and reporting |
| active | Live site in normal maintenance | Default target for updates, cache clears, and audits |
| offboarding | Project ending or being handed off | Trigger wind-down tasks and final backups |
| archived | Reference site with no active work | Skip update and reporting passes until needed |
Combining status with the other axes lets a team scope a release precisely. The same labels make it easy to exclude sites that have not launched yet or to trigger the offboarding routine at the right moment.
Set user roles before the next handoff
Roles are how MyKinsta separates one client's access from another's. Reviewing these roles before a busy quarter is one of the cheapest ways to prevent accidental cross-client edits.
Use bulk actions and the Activity Log for repeatable work
Once labels and names are consistent, bulk actions become genuinely useful. Together, they turn routine maintenance into a documented workflow rather than tribal knowledge.
Step up to the Kinsta API when filters stop scaling
The dashboard's single-label filter is a clean fit for small teams. Reports, scoped update jobs, and audit checks become repeatable jobs instead of manual filtering sessions.
An action checklist for a cleaner MyKinsta account
- Export the current Sites list to CSV and draft a consistent naming format.
- Rename every site to the new format, working in small batches.
- Decide on two or three label axes, such as client, site purpose, and lifecycle status.
- Apply labels in bulk from the Sites list, then tidy the vocabulary under Company settings.
- Review user roles for every team member and every client contact.
- Document a short routine for cache clears, updates, and reports that uses the new labels.
- Move any repeatable job that crosses multiple labels into the Kinsta API.
Keeping up with the wider WordPress ecosystem is easier when your portfolio is tidy. For a quick look at upcoming changes, browse our coverage of WordPress 7.1 beta 4 checklist and the broader WordPress 7.1 release features, and bookmark our note on the recent WordPress imagick rce patch for security hygiene.
Frequently Asked Questions
Is it safe to rename a live WordPress site in MyKinsta?
Yes. The MyKinsta display name is separate from the live domain, so SSH and SFTP credentials, MySQL database names, and the public server folder path stay the same. Deployment scripts that reference any of those values continue to work after a rename.
Can MyKinsta filter sites by more than one label at a time?
No. The built-in filter accepts a single label value, so it can show every commerce site or every active site, but not the intersection of the two. Combining multiple label axes in one query requires the Kinsta API.
Who can rename sites and change labels inside MyKinsta?
Company Owners, Administrators, Developers, and Site Administrators can rename a site from the Sites list or the site Info page. Bulk label changes follow the same permission rules, so it is worth reviewing roles before a large tagging session.
How many labels should an agency use per site?
Two or three labels per site is usually enough. A common split pairs a client or ownership label with a site purpose label, and adds a lifecycle status such as active or archived when the portfolio needs a maintenance view.
When does it make sense to move work into the Kinsta API?
Once daily operations require combining label values, generating reports across dozens of sites, or running scheduled update jobs, the API pays for itself. It is the right tool when the dashboard's single-label filter becomes the bottleneck.
Conclusion
Bringing order to a crowded MyKinsta dashboard is less about new features and more about using existing ones with discipline. A consistent naming format, a small label vocabulary, careful role assignments, and the Activity Log cover most of the daily work. When the portfolio grows past what one-label filtering can express, the Kinsta API takes over. Work through the checklist above in short passes, and the dashboard that once felt chaotic becomes a reliable view of the work in front of you.
