- Understanding Multisite From Aimogen’s Perspective
- Network Activation vs Site Activation
- Configuration Scope Is Critical
- API Keys and Usage Accounting
- Cron and Scheduling in Multisite
- Object Cache and Redis Are High-Risk in Multisite
- User Roles and Permissions Across Sites
- Chatbots and Frontend Scripts Per Site
- Performance Isolation Matters
- Updating Aimogen in Multisite
- What Is and Is Not Supported
- Final Perspective
This page explains how Aimogen behaves in a WordPress Multisite environment, what is supported, what requires special attention, and where limitations typically appear. Multisite changes the execution model of WordPress in subtle but important ways. Aimogen can work well in this context, but only if those differences are understood and respected.
Multisite is not just “multiple sites.” It is a shared runtime with shared risks.
Understanding Multisite From Aimogen’s Perspective #
In a multisite network, WordPress runs many sites on a single codebase, often sharing users, cron, caching layers, and sometimes even databases or object caches.
Aimogen operates per site, but it executes within a shared environment. That means one site’s configuration, automation, or load can affect others if boundaries are not enforced correctly.
This is the core mental model you need: Aimogen thinks per site, but the server thinks globally.
Network Activation vs Site Activation #
Aimogen can technically be network-activated, but that does not mean it should be by default.
When network-activated, the plugin code is shared across all sites, but configuration, prompts, campaigns, chatbots, and automation settings should remain site-specific. If Aimogen exposes any global settings in network admin, those should be treated as infrastructure-level controls only.
In most cases, activating Aimogen per site provides better isolation and fewer surprises, especially during setup and testing.
Configuration Scope Is Critical #
Each site in the network should be treated as an independent Aimogen instance.
System prompts, templates, automation schedules, limits, and API usage should not be shared implicitly across sites unless that is an intentional design decision. Content strategy almost always differs per site.
If Aimogen allows copying or importing configurations, use that explicitly. Do not rely on network-level inheritance unless you fully understand what is shared.
Implicit sharing is where multisite problems begin.
API Keys and Usage Accounting #
One of the biggest risks in multisite setups is API usage aggregation.
If all sites share a single API key, usage from every site accumulates into one quota. This makes limits feel unpredictable and failures harder to attribute to a specific site.
For serious multisite deployments, use separate API keys per site whenever possible. This gives you clear accounting, better isolation, and safer automation.
If separate keys are not feasible, enforce strict per-site limits inside Aimogen.
Cron and Scheduling in Multisite #
Cron behavior in multisite is frequently misunderstood.
By default, WP-Cron is shared across the network. Heavy automation on one site can delay scheduled tasks on others. Low-traffic sites may never trigger their own tasks at all.
If Aimogen automation is important on more than one site, a real server cron job is not optional. It must trigger cron reliably for the entire network.
Without this, automation will appear random and unfair between sites.
Object Cache and Redis Are High-Risk in Multisite #
Multisite combined with Redis amplifies object cache risks.
If cache keys are not properly namespaced per site, one site’s Aimogen state can leak into another’s. This leads to impossible-seeming bugs: jobs blocked on one site because another site is “running,” limits triggering unexpectedly, or automation freezing entirely.
Only use Redis in multisite if it is correctly isolated per site and tested thoroughly with Aimogen enabled on multiple sites at once.
If flushing Redis “fixes” Aimogen across the network, you have a cache isolation problem.
User Roles and Permissions Across Sites #
Multisite user roles are site-specific, even though users are shared.
Aimogen respects WordPress capabilities. A user who is an Administrator on one site may be an Editor or Subscriber on another. Aimogen actions should follow the role on the current site, not the network role.
Always test Aimogen features using real user roles on each site. Assumptions based on network admin access are often wrong.
Chatbots and Frontend Scripts Per Site #
Chatbots must be configured and tested per site.
Each site may have different themes, caching rules, CSP headers, or JavaScript environments. A chatbot that appears on one site may not appear on another even with identical Aimogen settings.
Treat chatbot deployment as site-specific frontend integration, not a network-wide toggle.
Performance Isolation Matters #
In multisite, one site can degrade the whole network.
Aggressive automation, large batch generation, or frequent maintenance jobs on a single site can consume cron time, PHP execution slots, and API quota in ways that affect all sites.
Stagger automation schedules across sites. Do not let multiple sites run heavy jobs simultaneously unless the hosting environment is designed for it.
Predictability matters more than raw throughput.
Updating Aimogen in Multisite #
Updates should always be tested on staging with multisite enabled.
An update that works on a single-site install may behave differently in multisite due to shared cron, shared cache, or shared users. Never update Aimogen network-wide without verifying automation, chatbots, and background jobs on at least two different sites.
If possible, pause automation on all sites before updating and re-enable it gradually afterward.
What Is and Is Not Supported #
Aimogen is compatible with WordPress multisite when each site is treated as an independent automation unit.
What works well:
Per-site configuration
Per-site content generation
Per-site chatbots
Per-site automation schedules
What requires care:
Shared API keys
Shared cron
Shared object cache
Network-level caching or security rules
What should be avoided:
Implicit sharing of prompts or limits
Unbounded automation across many sites
Assuming single-site behavior applies unchanged
Final Perspective #
Multisite multiplies both power and risk.
Aimogen can run cleanly in a multisite network, but only when isolation is intentional and infrastructure is treated seriously. The plugin does not magically become network-aware just because WordPress does.
If you design for separation, enforce boundaries, and respect shared resources, Aimogen behaves predictably on multisite. If you assume defaults are safe, small issues scale into network-wide failures.
In multisite, discipline is not optional.
