How to Safely Buy a WordPress Multisite Network Using Escrow: Verify Sites, Users, and Revenue

Understanding WordPress Multisite Networks

A WordPress multisite network lets you run dozens or hundreds of sites from a single installation, sharing core files, plugins, and user tables. This architecture is attractive for agencies, publishers, and entrepreneurs who want centralized management while keeping each site’s content separate. Understanding the shared database schema, network‑wide settings, and super‑admin capabilities is the first step before any purchase.

Because the network operates as a single codebase, any vulnerability or misconfiguration can affect every subsite simultaneously. Buyers must evaluate the network’s update history, the version of WordPress core, and whether custom mu‑plugins or drop‑ins are in use. A thorough technical audit reduces the risk of inheriting hidden debt that could surface after the deal closes.

Key Components to Inventory

Create a checklist that includes: the primary domain and any mapped domains, the list of active subsites with traffic metrics, the super‑admin accounts and their permissions, the set of network‑activated plugins and themes, and any custom code stored in mu‑plugins. This inventory becomes the baseline for verification during escrow.

Practical Audit Steps

Run a WP‑CLI command such as `wp site list --fields=url,blog_id,last_updated` to export every subsite’s URL and last update timestamp. Compare the output with the seller’s spreadsheet. Use `wp plugin list --network --format=csv` and `wp theme list --network --format=csv` to capture network‑activated extensions. Document any site‑specific plugins that are only active on a subset of subsites, as these will need individual license checks later.

Conducting Due Diligence on Sites, Users, and Revenue

Due diligence starts with traffic and revenue verification. Request read‑only access to Google Analytics, Matomo, or any analytics platform used across the network. Export the last 12 months of sessions, pageviews, and conversion data for each subsite. Cross‑reference these numbers with the seller’s reported earnings from ad networks, affiliate programs, or product sales.

User management is another critical area. Export the wp_users and wp_usermeta tables for the entire network. Identify super‑admins, site administrators, and any stale accounts. Verify that the seller can transfer ownership of all admin accounts without breaking SSO or membership plugins. If the network uses a membership plugin, confirm that subscription data and payment gateways are portable.

Revenue Stream Validation

Map every income source: ad impressions, affiliate commissions, e‑commerce orders, sponsorships, and any recurring subscriptions. Request invoices, payment processor statements (Stripe, PayPal), and tax documents for the past two years. Consistency between reported revenue and processor data builds confidence that the network’s cash flow is genuine.

Traffic Quality Checks

Run a bot‑filter audit using tools like Cloudflare Bot Management or the `wp statistics` plugin to separate human traffic from crawlers. Look for sudden spikes that could indicate purchased traffic. A clean traffic profile protects the buyer from overpaying for inflated metrics.

Verifying Ownership, Licensing, and Plugin Compatibility

Ownership verification goes beyond the domain registrar. Confirm that the seller controls the primary domain’s DNS records, the hosting account, and any associated SSL certificates. Use WHOIS history and registrar transfer logs to ensure no pending disputes. For each mapped domain, repeat the same checks.

Licensing is often overlooked. Network‑activated premium plugins and themes may have licenses tied to the seller’s account. Ask for license keys, purchase receipts, and the vendor’s transfer policy. Some vendors allow license reassignment; others require a new purchase. Document the status of each license in the escrow agreement to avoid post‑sale surprises.

Plugin Compatibility Matrix

Create a matrix listing every plugin, its version, license type, and whether it is network‑activated or site‑specific. Test the matrix on a staging environment that mirrors the production stack. This step reveals conflicts that could break subsites after the transfer, especially when PHP or MySQL versions differ between the seller’s host and the buyer’s target host.

Automated Compatibility Testing

Use a CI pipeline (GitHub Actions, GitLab CI) to spin up a fresh multisite container, import the database, install the exact plugin set, and run the WordPress test suite (`phpunit`). Failures flag incompatibilities before any money changes hands.

Structuring the Escrow Agreement and Milestones

The escrow agreement should enumerate every deliverable: full database dump (SQL), complete wp‑content folder, .htaccess, nginx/Apache config snippets, and a list of all third‑party credentials (CDN, SMTP, analytics). Attach the inventory checklist from Section 1 as an exhibit. Clear deliverables prevent ambiguous ‘as‑is’ claims.

Define milestones that mirror the technical transfer steps. Example milestones: (1) Seller uploads verified backup to escrow’s secure vault; (2) Buyer restores backup on a staging server and runs health checks; (3) DNS records are switched and SSL certificates re‑issued; (4) Buyer confirms all subsites load correctly and revenue tracking works. Each milestone triggers a partial release.

Dispute Resolution Clauses

Include a clause that specifies a 48‑hour window for the buyer to raise issues after each milestone. If a dispute arises, Escrows Click’s mediation team reviews the evidence (logs, screenshots, third‑party reports) and decides on fund release. Having this process predefined reduces the likelihood of prolonged disagreements.

Holdback for Post‑Sale Support

Reserve 10‑15 % of the purchase price as a holdback released after a 30‑day support window. The holdback covers any migration bugs, license re‑purchases, or revenue discrepancies discovered after go‑live.

Managing the Technical Transfer and DNS Cutover

Technical transfer is the most error‑prone phase. Begin by importing the database dump into a clean WordPress multisite install on the buyer’s hosting. Run the `wp search-replace` command to update the primary domain and any mapped domains throughout the database. Verify that the `siteurl` and `home` options for each subsite reflect the new domains.

Next, sync the `wp-content` folder, paying special attention to `mu-plugins`, `plugins`, `themes`, and `uploads`. If the network uses a CDN, update the origin URL in the CDN dashboard. Re‑issue SSL certificates via Let’s Encrypt or the buyer’s certificate provider, ensuring that each mapped domain validates. Test each subsite’s front end, admin dashboard, and any cron jobs.

DNS Cutover Checklist

1. Lower TTL on all A/AAAA/CNAME records 24 hours before cutover. 2. Update nameservers or A records to point to the new host. 3. Monitor propagation with `dig` and external tools. 4. Verify that email (MX) records remain functional if the network handles mail. 5. Confirm that analytics and tracking pixels fire on the new domains.

Post‑Cutover Validation Script

Deploy a lightweight script that curls every subsite’s homepage, checks for HTTP 200, verifies the presence of the Google Analytics tag, and confirms that the WordPress REST API returns a valid `site` object. Run the script every five minutes for the first hour after cutover.

Post‑Transfer Security and Ongoing Management

After the transfer, immediate hardening protects the asset from account takeover. Rotate all super‑admin passwords, enforce two‑factor authentication, and remove any unused admin accounts. Review the `wp-config.php` constants for `DISALLOW_FILE_EDIT` and `FORCE_SSL_ADMIN`. Apply the latest WordPress core, plugin, and theme updates on a staging site before pushing to production.

Implement a monitoring stack: uptime checks (e.g., UptimeRobot), security scanning (Wordfence, Sucuri), and automated backup verification. Schedule daily off‑site backups of both database and files. If the network runs membership or e‑commerce, set up transaction alerts for unusual patterns. These controls align with Escrows Click’s security best practices.

Ongoing Management Handoff

Provide the buyer with a runbook that documents: super‑admin credentials (in a password manager), renewal dates for premium licenses, CDN and SSL expiration calendar, and the escalation path for critical issues. A 30‑day post‑sale support window, funded from the escrow holdback, gives the buyer confidence while the seller assists with any unforeseen migration bugs.

Legal and Tax Considerations

Before funds are released, confirm that the seller can legally transfer all intellectual property, including custom code, graphics, and content. Request a signed assignment agreement that covers copyright, trademarks, and any third‑party licenses.

Consult a tax professional to understand sales‑tax nexus implications if the network sells digital products across multiple jurisdictions. Some states treat the transfer of a revenue‑generating website as a taxable event. Document the agreed tax treatment in the escrow agreement to avoid surprises during filing season.

Common Pitfalls and How to Avoid Them

Common pitfalls include underestimating the effort to re‑license premium plugins, forgetting to transfer third‑party API keys (e.g., Stripe webhooks), and neglecting to update hard‑coded URLs in custom code. Each of these can cause revenue loss or broken functionality days after the deal closes.

Another risk is hidden multisite network settings such as `COOKIE_DOMAIN`, `SUNRISE`, or custom `wp_sitemeta` entries that control domain mapping. If these are not replicated, subsites may become inaccessible. A full `wp_sitemeta` export and comparison between source and destination environments catches these issues early.

Final Checklist Before Release

- All milestones signed off by both parties. - Health‑check scripts report 100 % green for every subsite. - Revenue tracking matches pre‑sale baseline for at least 48 hours. - All licenses, API keys, and third‑party accounts transferred. - Escrow holdback released only after buyer’s written confirmation. Following this checklist ensures a clean, secure handover and protects both buyer and seller.