Taking over an existing WordPress site is rarely as simple as getting an admin login.
A site that's been online for a few years tends to accumulate history. Plugins were installed for reasons nobody remembers. An agency set up the hosting. Someone else controls the domain. A form sends data somewhere. There's a Cloudflare account, but nobody is quite sure whose. The developer who built the custom theme hasn't been involved in three years.
And the site works.
Mostly.
That's why the first job when inheriting a WordPress site isn't fixing things. It's understanding what you're now responsible for without breaking what already works.
Here's how we approach it.
1. Figure out who controls what
WordPress access is only one piece of the site.
Before making changes, we want to know where the important pieces live and who owns them.
That usually means identifying access to:
- WordPress
- Web hosting
- Domain registrar
- DNS
- Cloudflare or another CDN
- Source code repositories
- Google Analytics and Tag Manager
- Search Console
- Transactional email
- Form and CRM integrations
- Payment providers
- Third-party APIs
- Plugin and theme licenses
This can take longer than you'd expect.
We've inherited sites where the domain was registered by a former employee, DNS lived in an old agency's Cloudflare account, analytics belonged to somebody's personal Google account, and paid plugins were still licensed to the original developer.
None of those things are WordPress problems until something needs to change.
Then they become WordPress problems very quickly.
The goal isn't necessarily to move everything on day one. It's to know what exists, who controls it, and whether the organization can regain control if something goes wrong.
2. Make sure there's a backup we trust
Before updating WordPress, touching plugins, changing PHP versions, or cleaning anything up, we want a known-good backup.
Not just a checkbox in a hosting dashboard that says backups are enabled.
We want to know:
- What gets backed up?
- How often?
- How long are backups retained?
- Are the database and uploaded files both included?
- Are backups stored separately from the production server?
- Can one actually be restored?
That last question matters.
A backup isn't particularly useful if nobody knows whether it works.
For an established site, we'll often take an additional backup before the first meaningful round of changes even when the host already provides automated backups. It gives us a clean point to return to if we discover that some seemingly harmless update was holding together something unexpected.
3. Understand how the site was built
Two WordPress sites can look similar in a browser and be completely different underneath.
One might use a custom theme with a clean set of Gutenberg blocks. Another might depend on ACF flexible content. Another was built with Elementor. Another has a ten-year-old theme, a child theme containing years of patches, and several hundred lines of business logic in functions.php.
Before deciding what needs improvement, we need to understand the architecture that's already there.
We look at things like:
- Theme and child-theme structure
- Custom plugins
- Must-use plugins
- Gutenberg blocks and patterns
- ACF fields and content models
- Page builders
- Custom post types and taxonomies
- Theme modifications
- Custom JavaScript
- Build tooling
- Composer or npm dependencies
- Deployment process
- Code that doesn't appear to belong anywhere
The last category is more common than it should be.
This is also where we start distinguishing between something that's merely unfamiliar and something that's actually a problem.
Different developers make different architectural choices. Taking over a site doesn't mean rewriting everything according to our preferences.
If the existing system is understandable, maintainable, and doing its job, leaving it alone is often the right decision.
4. Find everything WordPress talks to
Modern WordPress sites rarely operate in isolation.
A contact form might send leads into Salesforce. Newsletter signups might go to Mailchimp. Ecommerce might depend on Stripe. Job listings might come from an external recruiting platform. A membership system might make API calls to another application.
Those integrations are easy to miss during a visual review because everything appears to happen inside the website.
We map the important dependencies before making significant changes.
That includes:
- Forms and form notifications
- CRM connections
- Email marketing platforms
- Payment gateways
- Webhooks
- REST APIs
- Authentication providers
- Search services
- Analytics and advertising scripts
- Scheduled imports and exports
- External feeds
- Transactional email providers
This is particularly important when replacing plugins.
A plugin that looks unused in the WordPress dashboard may be responsible for something that happens once a night, once a month, or only after a particular form submission.
Deleting it because "nothing seems to use it" is not a maintenance strategy.
5. Audit WordPress, plugins, and PHP
Only after we understand the site do we start looking seriously at updates.
We check the versions of WordPress, PHP, themes, and plugins, but version numbers alone don't tell the whole story.
An old plugin may simply need an update. It may also have been abandoned by its developer three years ago.
A plugin that's fully up to date can still be unnecessary, insecure, poorly maintained, or incompatible with a future PHP upgrade.
We look for:
- Outdated WordPress core versions
- Outdated plugins and themes
- Known security vulnerabilities
- Abandoned plugins
- Duplicate functionality
- Inactive plugins that don't need to exist
- PHP compatibility problems
- Missing or expired licenses
- Custom modifications that could be overwritten by an update
- Plugins that are critical to the site's operation
Then we decide how aggressively the site can be brought current.
Sometimes that's one routine maintenance session.
Sometimes the safest answer is a staged upgrade with testing between major changes.
6. Understand the hosting environment
A WordPress dashboard tells you surprisingly little about the environment running underneath it.
We want to know what happens below WordPress too.
That includes:
- PHP version and configuration
- PHP memory limits
- Database version
- Server resources
- Object caching
- Page caching
- CDN configuration
- WordPress cron
- Server-level cron jobs
- Filesystem permissions
- SSL configuration
- Staging environments
- Deployment workflows
- Server and application logs
This is often where performance problems become easier to explain.
A slow WordPress site isn't necessarily suffering from "too many plugins." It could be an expensive database query, an uncached API request, PHP workers being exhausted, an enormous autoloaded options table, poor cache configuration, or simply inadequate hosting.
Guessing is less useful than measuring.
7. Check DNS, SSL, and email
The website doesn't begin and end at the web server.
We check the domain's DNS records, SSL certificate, nameservers, mail records, and expiration dates as part of understanding the system.
This catches another category of inherited-site surprises.
Maybe the website is behind Cloudflare but nobody has access to the account. Maybe the domain expires in two months and renewal notices go to an employee who left years ago. Maybe transactional email is being sent directly through the web server and quietly landing in spam.
These aren't glamorous problems.
They're also exactly the kinds of problems that can take a perfectly functional WordPress site offline.
8. Put monitoring in place
We prefer to establish a baseline before making substantial changes.
At minimum, we want to know whether the site is reachable and whether the important pages are returning what we expect.
Depending on the site, that can also mean monitoring:
- Response time
- Expected page content
- SSL certificate expiration
- DNS changes
- Domain expiration
- APIs and JSON responses
- Scheduled jobs
There's an important distinction here between knowing that a server returned 200 OK and knowing that a website is actually healthy.
A broken WordPress page can return a successful HTTP status. So can a page containing a PHP warning, database error, or maintenance message.
Monitoring expected content as well as the HTTP response gives us a much better signal.
We built Sentinel partly because this became such a routine part of maintaining production websites. Monitoring from outside the infrastructure gives us an independent view of what visitors are actually able to reach.
9. Make the first changes boring
Once we understand the site, the temptation is to start fixing everything we've found.
We generally don't.
The first changes should be predictable.
Get the backups in order. Bring safe updates current. Remove obvious risks. Fix monitoring. Document access. Address known security issues. Establish a staging workflow if one doesn't exist.
Then watch what happens.
A website that's been operating for years has accumulated assumptions that aren't always documented in code.
Changing ten things at once makes it much harder to determine which assumption you just broke.
Boring changes are easier to test, easier to reverse, and easier to explain.
That's a feature.
10. Decide what actually needs to change
After the site is stable and understood, we can make better decisions about its future.
Sometimes the answer is straightforward ongoing WordPress maintenance.
Sometimes there are specific performance or technical problems worth addressing.
Sometimes the theme has reached the point where replacing it makes more sense than continuing to patch it.
And occasionally the underlying requirements have grown beyond what WordPress is particularly good at, and a custom web application is the better long-term answer.
That decision should come after understanding the system, not before.
We've seen plenty of old WordPress sites that were built well and simply needed someone to take care of them.
We've also seen newer sites where rebuilding was clearly less expensive than spending another few years working around fundamental architectural problems.
Age isn't the deciding factor. Maintainability is.
Taking responsibility before making changes
Taking over an existing WordPress site isn't really an update job.
It's a transfer of responsibility.
Before changing the system, we want to know how it's built, what it depends on, who controls its infrastructure, how we'd recover it, and how we'd know when something goes wrong.
Once those things are understood, WordPress maintenance gets much less dramatic.
Which is exactly how we like it.
Rootstuff provides custom WordPress development and ongoing website maintenance for businesses and agencies, including existing sites that need a new technical home.