WordPress Multisite: Show Posts From Another Subsite

You can display posts from another WordPress Multisite subsite three ways: switch_to_blog() inside a custom query, the REST API pulling from sibling sites, or a network content-sharing plugin. All three work. Which one you pick should depend on how often the content changes, how many subsites you're querying, and how much server headroom you have.

Why agencies and publishers need cross-subsite content in the first place

The request almost always arrives the same way. You built a Multisite network for a client — maybe a franchise with 30 location sites, a university with departmental sites, or a publisher with regional editions. Six months in, the marketing director asks: "Can the national blog posts show up on every location page automatically?"

It's a reasonable ask. It's also the moment the architecture decision you made a year ago either pays off or bites you.

Here's the business version of the problem. Someone on the team is currently copying and pasting. A regional editor duplicates the corporate announcement into eight subsites, re-uploads the featured image, re-sets the categories, and hopes nobody notices the typo they fixed on site three but not site seven. At 15 minutes per cross-post and 40 cross-posts a month, that's 10 hours — about $350/month at a $35/hour blended editorial rate, or $4,200 a year. A one-time build to automate it typically runs $1,500–$3,000. Payback in under nine months, and that's before you count the cost of stale content and inconsistent messaging.

If you're not yet running Multisite and are weighing whether it's the right structure at all, start with our complete WordPress Multisite setup and management guide before you architect anything cross-site.

What are the options for displaying posts from another subsite?

There are three practical families of approaches: query the other site's database directly with switch_to_blog(), fetch it over HTTP with the REST API, or physically copy the post with a plugin. Each has a different failure mode, a different performance profile, and a different long-term maintenance bill.

Option 1: switch_to_blog() — native, fast, and easy to abuse

WordPress ships with switch_to_blog() specifically for this. You switch context to another subsite, run a normal WP_Query, grab what you need, and switch back. No HTTP overhead, no authentication, no external dependency.

$sites = get_sites( [ 'number' => 5, 'site__not_in' => [ get_current_blog_id() ] ] );
$network_posts = [];

foreach ( $sites as $site ) {
    switch_to_blog( $site->blog_id );

    $q = new WP_Query( [
        'posts_per_page'      => 3,
        'post_status'         => 'publish',
        'no_found_rows'       => true,
        'ignore_sticky_posts' => true,
    ] );

    foreach ( $q->posts as $post ) {
        $network_posts[] = [
            'title'     => get_the_title( $post ),
            'permalink' => get_permalink( $post ),
            'thumb'     => get_the_post_thumbnail_url( $post, 'medium' ),
            'site'      => $site->blog_id,
        ];
    }

    restore_current_blog();
}

Two rules that separate a working implementation from a 4-second homepage:

Always call restore_current_blog(). Not switch_to_blog( 1 ). WordPress maintains a stack of switched contexts, and skipping the restore leaves global state polluted in ways that surface as bizarre bugs three weeks later.

Always cache the result. Wrap the whole loop in a transient with a sensible TTL:

$network_posts = get_transient( 'ts_network_latest' );
if ( false === $network_posts ) {
    // ...loop above...
    set_transient( 'ts_network_latest', $network_posts, 15 * MINUTE_IN_SECONDS );
}

Without caching, a homepage pulling three posts from 20 subsites can fire hundreds of queries per page load. With Redis object caching in front of it, the transient lives in memory rather than adding another wp_options row per site — which matters, because autoloaded options and transient bloat are among the most common causes of slow WordPress databases.

Option 2: The REST API — slower per call, but far more resilient

The REST API treats each subsite as an independent HTTP endpoint. You hit https://site-b.example.com/wp-json/wp/v2/posts?per_page=5&_embed and get JSON back.

This costs more per request than a database switch — you're paying for a full WordPress bootstrap on the remote end. But it buys you three things worth real money:

1. Server independence. If subsites eventually get split across separate hosts, or you move to a multi-tenant architecture, the code doesn't change.
2. Edge cacheability. JSON responses cache beautifully at the CDN layer, which means the expensive part happens once per TTL, not once per visitor.
3. Front-end flexibility. React widgets, mobile apps, and digital signage can all consume the same endpoint. Our WordPress REST API developer guide covers authentication and custom endpoints if you need fields core doesn't expose.

Use wp_remote_get() with a short timeout and a transient wrapper. Never let a slow sibling site block your homepage render:

$response = wp_remote_get( $endpoint, [ 'timeout' => 3 ] );
if ( is_wp_error( $response ) ) {
    return $stale_cache ?: [];
}

That fallback to stale cache is not optional in production. One subsite going down should degrade the network feed, not take down the parent site.

Option 3: Plugins that copy the post

Multisite Post Duplicator, Distributor (from 10up), and Network Shared Media all push a copy of the post into target subsites rather than querying live.

For editorial teams, this is often the right answer even though it's technically less elegant. A regional editor can adjust the headline for local audiences. The copied post gets its own permalink, its own SEO metadata, and its own analytics. Distributor in particular handles the "this is a copy, here's the canonical original" relationship gracefully.

The trade-off is reconciliation. When the source post gets corrected, do the 12 copies update? Distributor supports pull/push updates; most simpler duplicators don't. Ask that question before you commit, because the failure mode is 12 versions of a press release with three different phone numbers.

Which approach should you choose?

Choose based on who edits the content and how many sites are involved, not on which method sounds more sophisticated.

• Content is identical everywhere and never edited per site → switch_to_blog() with a transient. Single source of truth, zero duplication.
• Content needs local customization → a copy-based plugin like Distributor. Accept the duplication; you're buying editorial control.
• Network exceeds ~25 subsites → REST API with aggressive caching, or build a network-level index table.
• You're feeding a headless front end or non-WordPress consumer → REST API, no debate.

For very large publishers, there's a fourth path worth budgeting for: a single custom table at the network level that indexes every published post across every subsite (post ID, blog ID, title, permalink, date, primary term). A cron job or save_post hook keeps it current. Cross-site queries become one indexed SELECT instead of N site switches. Higher build cost, dramatically better ceiling.

The database reality nobody mentions in the tutorials

Here's the part that turns a clever feature into a support ticket six months later.

WordPress Multisite doesn't use one shared posts table. Each subsite gets its own set of tables — wp_2_posts, wp_2_postmeta, wp_2_options, and so on. A 40-site network isn't one database with 12 tables; it's roughly 400+ tables. That's fine for normal operation. It's why cross-site queries are structurally harder than they feel like they should be: there is no single SELECT that spans all posts unless you build one.

The performance consequence is direct. Every switch_to_blog() call flushes and rebuilds a chunk of WordPress's internal caches for the new site context. Do it 30 times on an uncached homepage and you've added real latency to the page most likely to be someone's first impression.

That matters commercially. According to Deloitte's Milliseconds Make Millions study, a 0.1-second improvement in mobile site speed increased retail conversion rates by 8.4% (2020). Meanwhile, WordPress powers 43.5% of all websites, according to W3Techs (2025) — so a lot of these networks are out there, and a lot of them are one badly-cached network feed away from a slow homepage.

Three mitigations, in order of impact:

1. Redis or Memcached object caching. Non-negotiable on Multisite. It turns repeated cross-site lookups from disk reads into memory reads.
2. Full-page caching with intelligent purge rules. When a post publishes on subsite 7, the network feed on subsites 1–40 needs to purge. Most caching plugins handle single-site purging fine and cross-site purging poorly.
3. Enough database resources to handle table count. Shared hosting plans that meter concurrent database connections will choke on a Multisite network long before they choke on the same content spread across separate installs. Our Multisite hosting setup and server configuration guide walks through what those requirements actually look like.

What this is worth to an agency

Run the numbers on a real client scenario. A franchise brand with 30 location subsites publishes eight corporate posts a month that must appear on every location site.

Year one saves about $4,100. Year two saves $6,500. And that ignores the softer wins: no version drift, no forgotten sites, no editor quitting because their job is copy-paste.

This is exactly the kind of work that turns hosting-plus-maintenance into a genuine retainer rather than a commodity line item. We've written before about how managed WordPress hosting gives marketing agencies a competitive edge — cross-site content automation is one of the concrete deliverables that justifies it. If you're still self-hosting client networks on a VPS you patch yourself, the math in why smart agencies outsource WordPress hosting applies doubly to Multisite, where a single misconfiguration takes down every client at once.

How TopSyde handles Multisite networks

Multisite is not a checkbox feature for us. Networks get Redis object caching configured for cross-site query patterns, cache purge rules that understand network relationships, and database resources sized for table count rather than raw traffic. Plans start at $89/mo per site — see current pricing and the full technical spec sheet for what's included at each tier.

We also handle the part nobody enjoys: migrating an existing network without breaking wp-config.php constants, domain mapping, or the wp_blogs table. Support responses come back in under 2 hours during business hours, and TopSyde Sentinel monitors every subsite for malware and integrity changes 24/7 — which matters more on Multisite, where a compromised plugin is a compromised network.

If you're running client networks and want a second opinion on the architecture before you commit to an approach, our agency hosting program includes an architecture review. Every plan carries a 30-day money-back guarantee, so migrating a network to test the setup costs you a month of attention, not a year of contract.

Frequently asked questions

Can I display posts from another subsite without a plugin?

Yes. switch_to_blog() combined with WP_Query is built into WordPress core and requires no plugin — roughly 20 lines of PHP in a theme file or small custom plugin. Wrap the results in a transient so you're not re-querying every subsite on every page load.

Does cross-subsite content cause duplicate content SEO problems?

Only if you copy full post bodies to multiple subsites without canonical tags. Displaying titles, excerpts, and links back to the original post is safe. If you're duplicating full content with a plugin, make sure it sets a canonical URL pointing to the source post — Distributor does this by default.

How many subsites can I query before performance suffers?

There's no hard number, but past roughly 20–25 subsites, per-request switch_to_blog() loops become noticeable without object caching. With Redis and a 15-minute transient, networks of 50+ subsites work fine because the expensive query runs a handful of times per hour rather than on every page view.

Is Multisite better than separate WordPress installs for this?

Multisite makes cross-site content sharing possible; separate installs make it awkward and API-only. But Multisite also means shared plugins, shared core version, and shared blast radius during an incident. If content sharing is a core requirement, Multisite usually wins. If the sites are genuinely unrelated, separate installs are safer.

Will a content-sharing plugin keep copies in sync when I edit the original?

Depends on the plugin. Distributor supports pushing updates to distributed copies; most lightweight duplicators create a one-time copy and never look back. Confirm update behavior during evaluation — reconciling drifted copies across 20 subsites manually is worse than the problem you set out to solve.

Colton Joseph

Founder & Lead Developer

20+ years full-stack development, WordPress, AI tools & agents

Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.

XLinkedIn