WordPress Portfolio Maintenance Audit Checklist

Before standardising maintenance across multiple WordPress websites, establish what exists, who owns it and where the operational risks are. This audit creates the baseline needed for a reliable support model.

The output should be more than a spreadsheet. A useful portfolio audit produces an accurate inventory, a prioritised risk register and a short action plan with named owners.

When to run a WordPress portfolio audit

Run the audit when an agency takes on maintenance clients, a marketing team inherits several brand sites, a company changes support providers, or nobody can confidently explain who controls domains, hosting and premium licences.

Repeat the review after acquisitions, major migrations or organisational changes. The technical stack often changes more slowly than the people responsible for it.

1. Website and business ownership

• Production URL, primary domain and aliases
• Brand, region or department responsible
• Business purpose and critical customer journeys
• Internal owner and authorised approver
• Expected lifespan: strategic, temporary campaign or scheduled for retirement
• Data sensitivity, transactions and regulatory considerations

Business context determines maintenance priority. A visually simple campaign site may deserve urgent support if it is tied to a time-sensitive launch.

2. Domain, DNS and infrastructure

• Domain registrar, account owner and renewal status
• DNS provider and authorised administrators
• Hosting provider, plan and account owner
• Production, staging and development environments
• CDN, firewall, object cache and email delivery services
• PHP, database and web-server versions

Record ownership separately from technical access. A previous agency may have administrator credentials while the legal account and billing relationship belong to somebody else.

3. Access and identity

• WordPress administrator accounts
• Hosting, SFTP, SSH and database access
• Password-manager location
• Multi-factor authentication status
• Shared or unidentified accounts
• Process for approving, reviewing and removing access

Remove accounts that no longer have a business purpose. Shared credentials make it difficult to identify changes and safely offboard a vendor or employee.

4. WordPress stack

• WordPress version and update policy
• Active theme, child theme and custom modifications
• Active, inactive and must-use plugins
• Page builder and reusable content system
• Custom code, APIs and scheduled tasks
• Premium licence owner, renewal date and site limits
• Unsupported, abandoned or duplicated components

Do not assume an inactive plugin is harmless. If it has no planned use, remove it after confirming that no data or deployment workflow depends on it.

5. Content and conversion functionality

List the functions that must survive every update:

• contact and lead forms;
• checkout, subscriptions and payment gateways;
• login, membership or learning areas;
• search and filtering;
• multilingual content;
• CRM, analytics and marketing automation;
• structured data and SEO controls.

Assign an owner to each external integration. A WordPress support provider cannot resolve an expired CRM account or payment configuration without the appropriate commercial contact.

6. Backup and recovery

• Backup frequency and last successful run
• Files, database and configuration included
• Off-site storage location
• Retention period
• Encryption and access to backup storage
• Date and result of the last restoration test
• Recovery-time and acceptable data-loss expectations

A green “backup completed” notification does not prove recoverability. Select representative sites and test restoration on a safe environment.

7. Monitoring and security

• Uptime and certificate monitoring
• Domain-expiry monitoring
• Vulnerability and malware signals
• Security and application logs
• Failed-login or privilege-change alerts
• Owner for alerts and escalation
• Incident history and unresolved findings

Monitoring without ownership creates noise. Every alert type needs a recipient who knows what action to take and when to escalate.

8. Performance and capacity

• Hosting resource limits and recent incidents
• Page and asset weight
• Caching layers and exclusions
• Database growth and scheduled jobs
• Traffic patterns and campaign peaks
• Core Web Vitals on representative templates

Use performance data to identify outliers rather than forcing every website to reach the same synthetic score. For detailed remediation, see our guide to improving WordPress Core Web Vitals.

9. Update and testing workflow

• Maintenance window and responsible person
• Staging availability and production differences
• Components excluded from automatic updates
• Pages and flows checked after changes
• Rollback procedure
• Change record and client notification process

Use the findings to group sites by risk and technical similarity. The safe portfolio update workflow explains how to turn that grouping into a maintenance process.

10. Request and escalation process

• People authorised to submit and approve work
• Primary request system
• Emergency communication route
• Priority and business-impact definitions
• Response targets
• Boundary between support and project work
• Reporting cadence and audience

If the expected service levels are unclear, use the website support SLA guide to define them.

Create a portfolio risk score

Area	Low risk	High risk
Ownership	Named business and technical owners	Unknown billing or account ownership
Software	Supported stack with current licences	Abandoned plugins or undocumented custom code
Recovery	Recent off-site backup and tested restore	Backup status unknown or stored only on production
Access	Individual accounts with MFA	Shared credentials and former users
Operations	Defined checks and escalation	Problems discovered by customers

Score each site consistently, then prioritise high-impact sites with high operational risk. Do not start by standardising a low-value site while a revenue-generating property has no tested recovery path.

Turn the audit into a 30-day action plan

1. Immediate: secure ownership, remove unsafe access and confirm recoverable backups.
2. First two weeks: address critical vulnerabilities, unsupported components and monitoring gaps.
3. Weeks three and four: document update groups, request channels, priorities and reporting.
4. Ongoing: reduce unnecessary stack variation and review the inventory quarterly.

The completed inventory is also the right input for budgeting. Use the guide to WordPress maintenance cost and pricing models to compare per-site plans, pooled portfolio capacity and separately scoped project work.

When the audit is part of a provider change, use the WordPress website handover checklist to transfer domains, hosting, access, licenses, analytics, backups and open work before offboarding the previous team.

From inventory to operating model

CodaStudio can help establish consistent WordPress maintenance for multiple websites or provide white-label WordPress maintenance for an agency portfolio.

To review your portfolio and identify the right support model, send the team your site count and current maintenance challenges.