How to Manage Multiple Websites Without Spreadsheets
To manage multiple websites well, you need four things: an inventory of every site, a named owner for each one, a written standard every site is checked against, and checks that run continuously. Spreadsheets can hold the first two. They can't do the last two, and that is where most portfolios start to drift.
At Vardot, we run hundreds of websites for UN agencies, universities, nonprofits, and media companies. For years, our support and customer success teams tracked them the way most teams do: spreadsheets, developer check-ins, and calendar reminders.
That held up while the portfolio was small. As it grew, every new security advisory or accessibility requirement meant someone checking site after site by hand.
This guide covers the approach we moved to, and the tool we built to run it.
Key Takeaways
- Managing multiple websites is a governance problem first and a tooling problem second.
- An audit shows one moment. Continuous checks catch what changes between audits.
- Start with an inventory and an owner for every site. Then write one standard with thresholds you choose.
- Govern the code as well as the live site. Much of the risk sits in dependencies nobody opened.
- Auditray, Vardot's agentic governance platform, runs this process across Drupal, WordPress, and other sites from one dashboard.
To manage multiple websites well, you need four things: an inventory of every site, a named owner for each one, a written standard every site is checked against, and checks that run continuously. Spreadsheets can hold the first two. They can't do the last two, and that is where most portfolios start to drift.
At Vardot, we run hundreds of websites for UN agencies, universities, nonprofits, and media companies. For years, our support and customer success teams tracked them the way most teams do: spreadsheets, developer check-ins, and calendar reminders.
That held up while the portfolio was small. As it grew, every new security advisory or accessibility requirement meant someone checking site after site by hand.
This guide covers the approach we moved to, and the tool we built to run it.
Why Spreadsheets Stop Working
A spreadsheet tells you what was true when someone last updated it. A website portfolio changes every week. Modules update, certificates expire, editors publish, and vendors deploy.
These are the usual signs a team has outgrown its spreadsheet:
- A security advisory lands, and nobody can say which sites are affected without asking developers.
- Different vendors maintain different sites, and each reports in its own format.
- A domain or SSL certificate expires because a business unit bought it on its own.
- Accessibility and privacy checks happen before launch, then rarely again.
- Leadership asks whether the sites are compliant, and the answer takes two weeks.
Audits Versus Continuous Governance
A website audit is a snapshot. It tells you where a site stood on the day someone reviewed it. That's valuable before a migration or redesign.
Sites rarely break on audit day, though. They regress later, after an update, a new plugin, or a content change. Continuous governance checks every site on a regular rhythm and records what changed.
| Website audit | Continuous governance | |
|---|---|---|
| When it runs | Once, or once a year | On a schedule and on demand |
| What it shows | Where a site stood that day | What changed, and when |
| Scope | Usually one site | Every site in the portfolio |
| Output | A report | A live status per site, with history |
| Best for | Migrations, redesigns, due diligence | Daily operations and compliance evidence |
You need both. A site assessment and audit sets the baseline, and continuous checks hold it.
6 Steps to Govern Every Site
Build one inventory
List every website you're responsible for. Include microsites, campaign sites, and the ones a department launched on its own. For each site, record the URL, CMS and version, host, owner, and maintainer.
Every later step depends on this list, so keep it current. We cover this step in detail in website governance starts with a site inventory.
Name an owner for each site
Every site needs one accountable owner and a clear maintainer, whether that's an internal team or a vendor. When an issue comes up, the question of who fixes it should already have an answer.
Write one standard
Define what a healthy site looks like, then make it measurable. Group checks into policies such as security, accessibility, SEO, and performance. Give each check a threshold and a severity.
No single framework defines a compliant website. Accessibility follows WCAG. Privacy rules depend on where your users are. Security has several frameworks of its own. Your standard will draw on a few of these, plus your own rules.
Keep thresholds realistic. A rule every site fails on day one gets ignored by week two.
Connect the code
Checks on the live site show you the surface. Much of the risk sits in the codebase: outdated packages, known vulnerabilities, and credentials committed by mistake.
In one production Drupal codebase in our beta workspace, Auditray mapped 956 packages. Only 147 were direct dependencies. The other 809 came in through those packages, so nobody on the team had chosen them directly.
Connecting repositories lets you track dependencies, vulnerabilities by severity, exposed secrets, and license posture. When a client or auditor asks for a software bill of materials (SBOM), you can export one.
Check continuously
Run checks on a schedule, and rerun them when you need to confirm a fix. The most useful signal is change over time: which controls were fixed, which regressed, and which issues are new.
A regression is the earliest warning you get. Catching it the week it happens is far cheaper than finding it in next year's audit.
Route findings and keep evidence
A finding only helps if it reaches the person who can fix it. Group findings by policy and owner so each team sees its own work.
Keep a history of every check. When someone asks whether a site met the standard last quarter, you can show them the record instead of rebuilding it.
What to Check on Every Site
Your standard will be specific to your organization. These are the areas most multi-site teams cover, with example controls for each.
| Area | Example controls |
|---|---|
| Availability and SSL | Uptime, valid SSL certificate, enforced HTTPS, domain expiry |
| Security | Vulnerable dependencies, exposed secrets, pending security updates |
| Access control | Multi-factor authentication, role-based access, idle session timeout, brute force protection |
| Accessibility | Accessibility score against WCAG, held to your threshold |
| Privacy | Analytics that load only after consent, such as Google Consent Mode v2 |
| SEO | Descriptive page titles, metadata, indexability |
| Performance | Response time, cache health |
| Maintenance | CMS and module versions, unused admin accounts |
Treat these as starting points and adjust them to your own requirements and regulations. For AI-era search, accessibility matters for more than compliance, as we explain in when accessibility belongs in your AEO plan.
How Auditray Runs This Process
We built Auditray to replace our own spreadsheet process. Our support and customer success teams needed to own every update across client sites and know each site still met its standard. We opened Auditray to the community as a beta at DrupalCon Rotterdam 2026, where Vardot was a Gold Sponsor.
Auditray is for any team, agency or in-house, responsible for more than a handful of websites. Here's how it maps to the six steps:
- Inventory: Add sites one at a time or bulk import a CSV. Tags and custom fields record owner, vendor, or region.
- Ownership: Invite members and organize sites by the fields that matter to your team.
- Standard: Build policies from controls, each with a threshold and severity. Clone a default policy and tighten it, or use AI to help draft a new policy for a requirement you need to monitor.
- Code: Connect GitHub, GitLab, or Bitbucket to see dependencies, vulnerabilities, secrets, and license posture, and export an SBOM.
- Continuous checks: Each site gets a readiness score and a list of findings you can reevaluate after a fix.
- Evidence: Control history shows what was fixed, regressed, or introduced over any period from 30 days to a year, and exports as a PDF.
The dashboard shows the whole portfolio at once: which sites are up, which are down or blocked, and which still need a codebase connected. Each site opens into views for site health and hosting, code, CMS, compliance, and settings.
Auditray works with any website, whether it runs on Drupal, WordPress, Sitecore, or a custom stack. It detects each site's technology and hosting stack automatically. Deeper CMS checks, such as user and role audits, connect directly to Drupal today.
It also reads from tools your team already uses, including Google Analytics, Google Tag Manager, Microsoft Clarity, Cloudflare, Semrush, and Sentry.
Auditray monitors and reports. Your developers or vendors make the fixes, and qualified people still make decisions about risk.
For the full story of why we built it and how policies work, read why we built Auditray.
Try Auditray Free
Auditray is free during the beta. Create a workspace, import your site list, connect one repository, and see where each site stands.
If you'd rather have a team run governance for you, Vardot's multisite operations service can set your standards and handle follow-through.