How to Audit a New Client's Digital Assets Before Taking Over Their Website

Taking over an existing website from another agency, a freelancer, or an internal team is structurally identical to buying a used car without checking the history report. On the surface, the frontend might look polished, fast, and fully functional. But underneath the hood, you are inheriting a complex, often undocumented web of third-party plugins, scattered DNS records, orphaned hosting accounts, and fragile API connections.

For growing web agencies, a poorly executed client handover is a serious operational liability. If a premium plugin license expires two days after you take over, the client will blame you. If the domain name is registered to their former developer and that person goes unresponsive, the resulting downtime becomes your emergency. Conducting a thorough digital asset audit before officially assuming responsibility is one of the most reliable ways to protect your agency's reputation and profitability.

This guide walks through a complete website takeover checklist: how to audit client web assets, uncover hidden technical liabilities, and map scattered infrastructure into a centralized, predictable record — using both current best practices and a few realities (like WHOIS privacy redaction) that trip up agencies who learned this process a few years ago.

1. Why Auditing Client Web Assets Is a Mandatory SOP

When you agree to host, maintain, or redesign a client's existing digital presence, you are adopting their technical debt. A structured digital asset audit achieves three objectives:

• Risk mitigation — identifies security vulnerabilities, outdated software, and single points of failure (e.g., a critical domain expiring in 48 hours).
• Scope definition — prevents "scope creep" by revealing hidden complexity. You cannot accurately quote a maintenance plan if you don't know the site relies on 45 premium plugins and a heavily customized, outdated server environment.
• Establishing authority — presenting a new client with a comprehensive audit report positions your agency as professional, organized, and detail-oriented from day one.

2. Phase 1: The "Keys to the Castle" (Credential Gathering)

Before you can audit anything, you need access. One of the biggest bottlenecks in taking over an existing website is waiting for clients to track down their logins. Don't accept a scattered email thread of passwords — use a secure credential-sharing tool (1Password, Bitwarden, or similar) and request these standard access levels:

3. Phase 2: The Domain and DNS Audit

The domain is the foundation of the client's digital existence. Mishandling domain transitions causes catastrophic downtime and lost email. Start at the very top of the DNS chain.

Verify legal ownership — and know that WHOIS looks different than it used to

Never assume the client legally owns their domain. Amateur or unscrupulous developers sometimes register client domains under their own personal registrar accounts. Running a WHOIS lookup is still the right first move, but the results won't necessarily hand you a name.

Since the EU's GDPR took effect and ICANN introduced its Temporary Specification for gTLD registration data in 2018, registrars have been required to redact most personal registrant details from public WHOIS output by default. In practice, a public WHOIS or RDAP (Registration Data Access Protocol, the structured successor to WHOIS) lookup on most domains today will show fields like "Redacted for Privacy" instead of a name, address, or phone number. A handful of country-code TLDs (like .us) still legally prohibit privacy redaction, but for the average .com client domain, don't expect WHOIS alone to prove ownership.

What this means for your audit:

• Use ICANN's Registration Data Lookup Tool or your registrar's own lookup to confirm the registrar, creation/expiration dates, and nameservers — this data is still public.
• To confirm the actual owner, you'll typically need direct login access to the registrar account itself (this is why the credential-gathering phase above matters so much), or a signed statement/invoice from the client showing they purchased the domain.
• If the domain is not accessible through an account the client controls, and the current registrant can't be verified, treat this as a red flag and initiate a domain transfer conversation immediately. Leaving a domain in a former developer's name exposes your client to a digital hostage situation.

Audit the DNS zone file

Log into the DNS manager (whether at the registrar or a CDN like Cloudflare) and document every record. You must not break email or third-party authentication during a migration.

• A records & CNAMEs: Where is traffic actually pointing? Are there legacy subdomains (dev.client.com, old.client.com) that need to be deprecated?
• MX records: Where is email hosted (Google Workspace, Microsoft 365, etc.)? Never touch MX records unless you're explicitly migrating email.
• TXT / SPF / DKIM / DMARC: Are email authentication records intact? A bad DNS migration can send every outbound company email straight to customers' spam folders — or break domain validation for SSL certificates and other third-party integrations.

The TTL countdown, done correctly

If you're planning to migrate the website to your agency's hosting, lower the Time To Live (TTL) on the records you intend to change to 300 seconds (5 minutes) — but timing matters more than the number itself.

Lowering the TTL doesn't take effect the moment you save it. Resolvers around the internet are already caching the old record at the old TTL, and they won't check in again until that old TTL expires. So the real rule is: lower the TTL to 300 seconds for at least as long as the current TTL's full duration before you plan to cut over — commonly 24–48 hours, since many production A records default to a 4-hour (14,400 second) or 24-hour (86,400 second) TTL. Only once that window has passed can you be confident that resolvers worldwide are honoring the new, short TTL — which is what actually makes your eventual IP change propagate quickly. After the migration is confirmed stable, raise the TTL back to a normal production value (typically 1–24 hours) to reduce unnecessary query load on your DNS provider.

4. Phase 3: The Server and Hosting Environment Check

Once routing is verified, analyze the container holding the website. You need to know if the current hosting is robust enough to support your maintenance efforts, or if it needs an immediate migration.

PHP version: the single biggest overlooked liability

This is the section that ages fastest in any audit checklist, so treat whatever PHP version you find as a moving target and check it against PHP.net's current support table before you finalize any recommendation. As of mid-2026:

• PHP 7.4 and 8.0 have been end-of-life since November 2022 and December 2023 respectively, and are receiving zero security patches of any kind.
• PHP 8.1 reached end-of-life on December 31, 2025.
• PHP 8.2 is in its final year of security-only support and reaches end-of-life on December 31, 2026 — worth flagging explicitly to any client still on it, since a site inherited today on 8.2 will need another PHP upgrade within the same maintenance-plan year.
• PHP 8.3 and 8.4 are the versions to standardize on for a new take-over in 2026, with 8.4 supported into 2028. WordPress.org's own hosting requirements page currently lists PHP 8.3+ as the recommended baseline.

Despite this, a meaningful share of the web is still running PHP 7.x in production — industry usage trackers have put it around 30% of all PHP-powered sites in recent surveys — so don't assume a client's site is current just because it "works fine." An unpatched PHP version is an open, unpatchable attack surface for any vulnerability disclosed after its end-of-life date, and under frameworks like PCI DSS or SOC 2, running EOL software without compensating controls is typically treated as a compliance gap during an audit.

Memory limits and resources

WordPress's own hard-coded default is a 40MB memory limit on the front end and 256MB for admin-side operations — both are too low for a real production site. In practice:

• 256MB is a sensible general-purpose target for most business sites running a modern theme, a handful of plugins, and basic caching.
• 512MB is more realistic for sites running page builders (Elementor, Divi, Bricks) or a small WooCommerce store.
• 768MB–1GB may be genuinely needed for larger WooCommerce catalogs, multilingual sites (WPML/Polylang), or sites running scheduled imports.
• If a site needs meaningfully more than that just to load normally, treat it as a symptom worth investigating — usually a memory-leaking plugin or a poorly optimized import job — rather than something to solve by raising the ceiling indefinitely.

Storage and other server checks

Audit the server control panel for bloat: gigabytes of old backup .zip files, uncompressed media libraries, or abandoned staging copies are common on inherited sites and are worth flagging even when they're not urgent, since they slow backups and inflate hosting costs.

5. Phase 4: The CMS, Theme, and Plugin Audit

This is where the majority of technical debt lives. We'll assume a WordPress environment here, since it remains the dominant CMS in the agency market, but the same logic applies to any platform.

The premium license crisis

A standard business WordPress site might run 20–40 plugins, with 5–10 of them "premium" and tied to a paid annual license key (WP Rocket, Gravity Forms, Advanced Custom Fields Pro, and similar). You need to identify who holds the license for every premium asset.

Often, the outgoing agency activated these plugins using their own developer/agency-wide license. The moment that relationship ends, those plugins stop receiving updates — including security patches. Map out:

• Which plugins require a premium license?
• Is the license tied to the client's payment method, or the old developer's?
• Will the client need to purchase their own license, or will you roll it into your agency's master license as part of a care plan?

Security and malware scanning

Never take over a site without running a deep malware scan first, using both a server-side scan and, ideally, a second opinion from a different tool — no single scanner catches everything. Two of the most widely used WordPress security plugins in 2026 are:

• Wordfence, which scans files directly on the server and runs an in-application firewall. Its strength is real-time threat intelligence against novel exploits for paying customers; the trade-off is a heavier load on shared hosting, and free-tier users typically receive new malware signatures and firewall rules about 30 days after premium users.
• MalCare, which runs scans off-site to reduce server load and includes more automated one-click cleanup in its paid tiers.

Sucuri's cloud firewall is another common option, particularly for agencies that want a managed cleanup service bundled in. No scanner reliably catches everything on its own — database-stored malware and infections inside premium (non-repository) themes and plugins are common blind spots across these tools — so treat a clean scan as a strong signal, not a guarantee, and pair it with a manual review of the user list and recently modified files. Delete any unrecognized admin accounts and force a password reset for every remaining user before you take the account live.

6. Phase 5: Tracking the Assets

After completing your digital asset audit, you'll have a large amount of operational data: registrar logins, DNS host details, expiration dates for domains and SSL certificates, premium plugin license keys, and billing responsibilities.

If you store this in a static spreadsheet, it will go stale within a month. A premium plugin will expire, a domain renewal notice will go to the wrong inbox, and a critical piece of the site will break without warning. Most modern agencies solve this by pushing audit data into a dedicated asset-tracking platform during onboarding — tools built for exactly this purpose (InstaRenewal is one option) typically offer:

• Asset mapping — linking a client's domain directly to its hosting container and DNS manager in one dashboard.
• Automated expiration tracking — flagging domain and SSL expiration dates ahead of time (commonly 30/15/7-day alert windows) rather than relying on someone remembering.
• A "who pays" ledger — tagging every premium plugin and server cost as either "client billed direct" or "agency resold," so nothing gets silently absorbed as a cost the agency never passes on.

If you're comparing platforms, weigh a dedicated tracker against simply combining a password manager (1Password/Bitwarden) with a shared calendar of renewal dates — for a small number of client sites, that combination can cover the basics; the dedicated-tracker approach pays off once you're managing renewals and licenses across a larger portfolio.

7. Conclusion: The Handoff Agreement

Once the audit is complete and the assets are logged somewhere durable, generate an "Audit Findings & Transition Report" for the client. This report should clearly outline the current state of their digital infrastructure, flag any critical vulnerabilities (an EOL PHP version, a domain you couldn't verify ownership of, an unpatched plugin), and lay out the concrete steps needed to stabilize the asset.

A strict, repeatable website takeover checklist turns a potentially chaotic and unprofitable transition into a smooth, authoritative onboarding experience. It protects your agency from inherited liability, sets clear boundaries for your maintenance scope, and builds real trust with a new client from the very first week.

---

Sources consulted: PHP.net's official supported-versions page, WordPress.org's hosting requirements documentation, ICANN's registration data policies, and current WordPress security-plugin comparisons (accurate as of mid-2026 — always verify PHP end-of-life dates and WordPress requirements directly, since these schedules update annually).