Affiliate Programs on WordPress Multisite: One Network, One Program, or Many?
Multisite blurs the lines an affiliate program depends on — whose cookie, whose order, whose payout. The three architectures that work, and the cross-domain tracking trap to avoid.
WordPress multisite answers "how do I run five sites from one dashboard." Affiliate tracking answers "who referred this order on this site." Put them together and the prepositions start fighting: a partner's cookie lives on one domain, the order happens on another, the payout comes from a third entity, and the plugin was activated network-wide by an admin who assumed it would sort itself out.
It doesn't sort itself out — but it does sort cleanly once you pick one of three architectures on purpose.
Architecture 1: independent programs per site
Each subsite activates the affiliate plugin for itself, with its own partner roster, rates, referrals, and payouts. Nothing is shared; the network is just hosting.
This is the right shape when the sites are genuinely different businesses — different brands, audiences, or owners under one technical roof. A partner promoting your coffee brand has no reason to appear in your bookbinding brand's roster, and separate programs keep every report, payout, and tax question cleanly attributable to one entity. The cost is duplicated administration: five programs to run, five rosters to vet, five payout runs. That cost is real but honest — it mirrors the fact that you're running five businesses.
Most multisite affiliate setups should start here. It's also the architecture that assumes the least from your plugin: per-site activation is just WordPress working normally, with each site's tables and settings isolated by design.
Architecture 2: one flagship program, several satellite sites
One site — usually the main store — hosts the program: applications, portal, payouts all live there. The other subsites participate only as traffic destinations: partner links point at them, and conversions there credit the central program.
This fits the common "one brand, several properties" case: a store plus a docs site plus a landing-page factory. The catch is the tracking span. If your subsites are subdirectories (example.com/shop, example.com/docs), one first-party cookie covers everything and life is simple. Subdomains (shop.example.com, docs.example.com) can share a cookie set on the parent domain — check that your tracking cookie's domain setting allows it. But separate domains (brand-a.com, brand-b.com) cannot share first-party cookies at all; a click that lands on one domain and converts on another needs the referral parameter carried across in the link itself, or the conversion silently loses its attribution. Design your partner links to land on the domain where checkout happens, and the problem mostly disappears.
Architecture 3: one roster, per-site programs
The hybrid: partners apply once and exist network-wide, but rates, referrals, and reporting stay per-site. Attractive on paper for agency networks and franchise-like setups — one vetting pipeline, one partner identity, local economics. In practice this is the architecture that demands the most from software: per-site commission overrides, per-site reporting rollups, and payout consolidation across sites (one monthly payment covering earnings on three stores, itemized per store, from the right legal entity). If your plugin wasn't built for it, you'll end up simulating it with duplicated accounts anyway — which is Architecture 1 wearing a trench coat. Choose it only when the consolidation is worth genuine configuration effort.
The traps that don't care which architecture you picked
Network activation as an accident. Activating an affiliate plugin network-wide because the button was there gives every subsite — including the staging blog nobody remembers — a live affiliate program with default settings. Activate per-site, deliberately, on the sites that mean it.
One payout entity for many programs. If subsites belong to different legal entities but one wallet pays all partners, you've quietly created inter-company accounting and tax reporting on behalf of whichever entity owns the wallet. Match the paying entity to the program, or document the arrangement properly.
Cross-site fraud blindness. A partner self-referring on site B looks clean from site A's dashboard. Whatever architecture you run, review referrals with network-level eyes — same buyer identities, same IPs, same coupon patterns across sites — because your partners experience your network as one thing even when your databases don't.
Multisite doesn't make affiliate tracking harder; ambiguity does. One deliberate architecture, cookie span verified, entities matched to programs — and the network becomes what it promised: five sites, one dashboard, no fighting prepositions.