Post Indexer - WordPress Plugin

Post Indexer Setup Guide for WordPress Multisite Networks

Post Indexer is useful not as a standalone widget or search form, but as an underlying technical layer for a WordPress Multisite network. It pulls posts from different sites across the network into a shared index so other network-wide features can search, display, or analyze published content without manually checking dozens of separate sites. In this guide, we will walk through how to approach installation safely, which settings to review after activation, when to rebuild the index, and how to confirm that data is actually making its way into the shared list.

The key thing to understand is that Post Indexer does not replace the standard WordPress search on a single site. Its job is to provide a shared data layer for a Multisite network. That is why setup starts not with result design, but with administrator decisions: which sites to index, which post types to include, how far back to pull older content, and what to do if the stats screen stays empty.

This guide is especially important for older networks that already contain hundreds of published items. After installation, the plugin usually does not fill the index with past content immediately, so the initial run needs to be deliberate, with attention to server load and verification of the result. Do not start with a full rebuild on a live network unless you have a backup and a clearly defined maintenance window.

From here, we will focus on practical configuration: from preparing Multisite itself to troubleshooting issues with private sites, database tables, outdated versions, and integrations with plugins that read from the shared index.

What problem a network-wide post index actually solves

In a standard WordPress installation, each post lives in the tables of a specific site. On a single site, that works well: search, archives, categories, and widgets all operate within one content base. In Multisite, the picture is different. A network may include a main site, dozens of topic-specific subsites, separate editorial teams, educational blogs, branch offices, regional pages, or client projects. In many cases, visitors or editors do not need the feed from one specific subsite - they need a view across the entire network.

Post Indexer creates a shared index that collects content from selected sites. That allows other tools to display the latest posts across the network, build global search, show tag-based feeds, or give administrators an overview of network activity. The plugin itself stays in the admin area and does not have to output a public-facing block on the front end.

Where the index is especially useful

Post Indexer becomes genuinely useful where the network functions as a unified product rather than a collection of isolated sites. For example, a university network may want to feature faculty posts on the homepage. A media project may need to aggregate recent content from multiple editorial sites. A blogging community may want to offer users a shared page of newly published posts.

• The network main site can display recent posts from child sites without manually copying content.
• An administrator can see which sites publish the most content and which post types are entering the index.
• An additional global search or global post listing plugin gets a single source of truth.
• An editorial team can quickly review new content across the network and decide what should be featured on the homepage.

What the plugin does not do on its own

It is important not to expect Post Indexer to do more than it is designed to do. It does not create a finished search results page layout, does not make the search algorithm smarter by itself, and does not turn the network into a catalog without additional tools. The official description makes it clear that this is a background plugin intended to support other features.

Practical takeaway: set up the index first and make sure it is being populated, then connect any public output, global search, or custom results template.

Who Post Indexer is for, and when another approach makes more sense

Post Indexer only really makes sense for WordPress Multisite. On a single site, it does not deliver on its core purpose, because WordPress already stores posts in one unified context there. If you need search for a single site, you are better off looking at dedicated search plugins, standard search tuning, SearchWP, Relevanssi, or ElasticPress.

Good use cases

The plugin is a good fit for networks where content needs to be aggregated without duplicating posts onto the main site. That is an important difference from solutions that import content via RSS or create post copies. An index lets you build output based on the original publications while keeping links pointed to the source site.

• A blog network where the main site should show new posts from all subsites.
• An educational platform where different departments or courses publish their own materials.
• A corporate network of branch sites that needs a shared news overview.
• An editorial Multisite setup where the administrator wants visibility into activity by site and post type.

When not to use it

If you have one site, a small page catalog, or a task that simply comes down to improving search relevance, Post Indexer is an unnecessary extra layer. It also needs to be handled carefully on very large networks: index rebuilds and frequent queries against network-wide data can affect both the database and the WordPress scheduler.

You should also pay attention to support status. The WPMU DEV repository labels the plugin as an older unsupported product published for developers who are prepared to maintain it for their own use cases. That does not mean it is automatically unusable, but it does change the approach: testing on a site copy, checking the version, and treating security seriously become mandatory.

What to check before installing it on Multisite

For a plugin like this, preparation matters more than uploading the ZIP file itself. Post Indexer operates at the network level, so a configuration mistake can affect not just one page, but the entire publishing flow between sites. Before installation, review the environment, permissions, backup status, and the actual goal of the rollout.

Platform and administrator permissions

The plugin should be installed and activated from the network admin area. In Multisite, plugins can be activated for one site or for the entire network, but tools that manage shared network data usually require network activation. Make sure you have super admin privileges and access to the Network Admin area.

• Confirm that the site is actually running in WordPress Multisite mode, not as a single-site installation.
• Create a backup of both files and the database before the first run.
• Decide which sites should be included in the index and which should be excluded.
• Review privacy settings on subsites: if a site asks search engines not to index it, that may affect whether its posts enter the shared network index.
• Schedule the first full crawl for a low-traffic period.

Version and security

With older network plugins, you cannot rely on the rule of thumb that "if it activates, it must be fine." Publicly available information shows that early versions of Post Indexer had vulnerabilities that were later fixed, so you should not leave an old archive on a production site without checking it. The minimum safe approach is to use the newest available branch from the official WPMU DEV repository, review the changelog, and test it on a site copy.

If you find a version older than the one marked as fixed in security sources, do not deploy it to a live network. Update the plugin files first, verify compatibility on a staging environment, and only then plan the rollout.

How to define the goal before launch

Before installing the plugin, it helps to write down exactly what should exist after indexing is complete. For example: "the main site will have a page of recent network content," "the editor needs an admin list of the latest publications," or "the global search plugin should be able to find posts from child sites." That kind of definition helps you avoid enabling unnecessary post types and rebuilding the index without a clear reason.

Installation and the first post-activation check

The installation process itself looks like a standard WordPress plugin install, but it must be done from the network context. If you are uploading the archive manually, make sure that the actual plugin folder ends up inside wp-content/plugins, not an outer archive that contains documentation or an extra nested directory.

Basic sequence

1. Open the WordPress network admin panel through My Sites - Network Admin.
2. Go to Plugins and upload the Post Indexer archive using the standard WordPress flow.
3. After installation, choose Network Activate so the plugin runs across the entire network.
4. Open Settings - Post Indexer in the network admin area.
5. Review the statistics, global settings, and index rebuild tabs.

When you first open the plugin, the stats may be empty. That is normal if older posts have not been added to the index yet or if no new content has been published since installation. Do not treat an empty screen as a failure until you have reviewed the settings and created a test post on a site that should be indexed.

A quick test without a full rebuild

It is better not to start by crawling the entire network. Create or update one published test post on a site that should be indexed. Then go back to Settings - Post Indexer and check whether it appears in the stats or in the list of recently indexed posts. This kind of test confirms that the basic publication hooks are working without putting unnecessary load on an older content database.

Best Post Indexer settings after installation

Detailed setup comes down to three decisions: which sites participate in the index, which post types should be included, and how to handle already published content. This is not a place to enable everything indiscriminately. The broader the index, the more data it stores and the heavier rebuild operations become.

Choosing post types

In the global settings, you can choose which post types should enter the index. For a typical network, the default starting point is standard Posts. Pages should only be added if they truly need to appear in global search or a public catalog. Custom post types should be enabled only after you confirm that the plugin reading the index can display them correctly.

Excluding individual sites

Post Indexer adds network-level actions for individual sites: you can disable indexing, edit parameters, rebuild the index only for a selected site, or review its stats. That is far more useful than a single on/off switch for the whole network. For example, an internal editorial site, a staging subsite, or an archived project is usually better excluded so its posts do not show up in public lists.

Practical order of work

Open Sites - All Sites and review the network site by site. For each one, decide whether its content should be visible in the shared index. If a site is audience-restricted, contains test content, or duplicates primary content, disable indexing for it. After making changes, return to the stats and verify that new posts from that site no longer appear in the shared selection.

Index depth and older publications

The settings allow you to limit the time range of content that enters the index. On large networks, that is not just a cosmetic option - it is a way to control data volume. If the homepage only needs recent material, there is no reason to index archives going back many years. If you are building a full historical search across the network, the depth should match that goal, but the initial run is still best handled gradually.

Safe strategy: first enable only the required post types, test one site, then rebuild the index for a few sites, and only after that run a full network-wide crawl.

How the index works: from publication to global output

To troubleshoot Post Indexer correctly, you need to understand the data path. When a post is published on a subsite, the plugin should add information about it to the shared index. Then another tool reads that index and builds the final result: a feed, a search result, a widget, a report, or a custom template. If something breaks anywhere in that chain, public output may stay empty even though the post itself exists on the subsite.

Three levels of verification

Do not start troubleshooting from the public page. Post Indexer gives you a shorter path. First, make sure the post is published and the site is allowed to be indexed. Then check Post Indexer statistics. Only after that should you test the widget, shortcode, or global search plugin.

1. On the subsite, the post must be published, not saved as a draft or private item.
2. The site must be allowed for indexing both in Post Indexer settings and in WordPress reading settings.
3. The Post Indexer stats should show recently indexed posts or data by post type.
4. The plugin displaying the shared list must read from the same index and must not be filtering out the required post type.

Why source links matter

One of the reasons to use an index instead of copying content is to keep the content on its original site. If you are building a "new across the network" page, the link should lead to the original post, not to a manually created duplicate on the main site. That reduces confusion for editors and helps avoid multiplying identical content in the database.

Practical example: a page of recent network content

Imagine a network of educational blogs. Each course has its own site, instructors publish notes and assignments, and the main site needs a page showing the latest content from across the network. In that setup, Post Indexer is responsible for the shared index, while public output is handled by a compatible tool, such as a plugin for recent global posts or custom code that knows how to work with the network index.

Goal

Create a page on the main site that displays the latest published posts from approved subsites. When a user clicks an item, they should land on the source site for that post, and the administrator should understand why a specific item did or did not appear in the list.

Preparation

• Post Indexer is installed and enabled at the network level.
• The Posts type is included in the index.
• Test and restricted subsites are excluded through Sites - All Sites.
• A new published post has been created on one approved subsite.
• A compatible public output tool is available and reads from the shared index.

Steps

1. Open Settings - Post Indexer and confirm that the new post appears in the stats or under recently indexed content.
2. If older posts also need to be included, rebuild the index for one site first, not for the entire network.
3. Create a page on the main site, for example "Recent Network Content."
4. Add output from a compatible plugin. Older WPMU DEV solutions sometimes used a shortcode format like [globalrecentposts number="20" content_characters="250" show_avatars="yes" avatar_size="40"], but use only the syntax available in your installed version.
5. Publish the page and open it in a private browser window.

Checking the result

The page should show posts from approved sites. Check not just the title, but also the link. It should point to the original publication. If the output shows posts from the main site but does not see child sites, go back to the Post Indexer stats and verify whether posts from child sites actually entered the shared index.

A common point of failure

If a site is marked as discouraged from search engine indexing in Settings - Reading, Post Indexer may not include its content in the way you expect. Check that setting on the specific subsite, not only in the network admin area. After changing the setting, create a new test post or rebuild the index for the selected site.

Rebuilding the index without unnecessary load

The Rebuild Index tab is meant for older content that was published before the plugin was installed, or for correcting situations where settings were changed after the first run. The official description warns that a rebuild may take a noticeable amount of time and may affect server performance. This is not a button to press "just in case."

When to rebuild the entire index

A full rebuild makes sense if you have just introduced Post Indexer into a mature network, changed the set of indexed post types, or restored the plugin tables after a failure. If the issue affects only one site, it is better to rebuild the index just for that site through the site list. That is faster and easier to troubleshoot.

Recommended order for a live network

1. Back up the database.
2. Exclude test, archived, and restricted sites from the index.
3. Rebuild the index for one small site first and review the stats.
4. Run the full crawl during a low-activity period.
5. After it completes, check the post count, recently indexed content, and the behavior of the public output.

Can posts be published during a rebuild?

WPMU DEV support discussions indicated that publishing during a rebuild should not break the process, but a newly published post may not appear in the index immediately if that site has already been processed. In practice, that means simple validation: after the rebuild, create one new test post and confirm that it enters the index. If it does not, wait for the next cycle or rebuild the index for that specific site.

Do not use rebuilds as a routine substitute for normal synchronization. This is a recovery and initial population tool, not a daily manual procedure.

Connecting it to global search, lists, and custom templates

Post Indexer is often needed not as an end-user feature by itself, but as a foundation for other network tools. In the older WPMU DEV ecosystem, it was associated with global site search, global tags, recent network posts, a recent posts RSS feed, and user activity tools. Some of those solutions are also part of the legacy stack, so review their current status separately before adopting them.

Global search

If your goal is search across the entire network, Post Indexer can serve as the data source for a compatible global search tool. But it does not handle ranking, match highlighting, custom field search, or a polished results template. For modern projects, it may be more practical to use SearchWP, Relevanssi Premium, or ElasticPress if what you really need is search relevance and active support.

Recent posts and editorial curation

For a page of recent content, Post Indexer is a more natural fit. You do not need a complex search algorithm there: you just need an up-to-date index of published posts and compatible output. What matters is setting the right limits by site and post type so that test content, internal pages, and restricted content do not appear in the curated list.

Custom development

The Post Indexer repository mentions that the plugin is useful to developers as a foundation for network-level functionality. If you are building custom output, do not query internal tables directly unless you understand their structure and filters. A safer approach is to study the plugin classes, existing query functions, and available filters, and keep your changes in an mu-plugin or separate plugin rather than editing Post Indexer files directly.

Editing the plugin core will make updates and rollbacks harder. If you need to change public output, build a separate layer that can be disabled independently of the indexer.

Common problems and how to troubleshoot them

Post Indexer issues usually do not show up as an obvious error message on the site. More often, they appear as empty statistics, missing posts, or incomplete global output. For troubleshooting, it helps to work from the simple checks to the more complex ones: publication state, site settings, index settings, database tables, the connected plugin, and server load.

Statistics are empty after installation

Symptom: the statistics tab shows no posts even though the network already contains published content. One possible reason is that the plugin started tracking only new posts after installation, while older ones have not yet been rebuilt into the index.

Check a new test post on an approved site. If it appears in the stats, basic synchronization is working. Then rebuild the index for one site first. If everything looks correct after that local rebuild, you can plan a full crawl.

Posts from one specific site do not enter the index

Symptom: posts from some subsites appear, but one site is missing. Check the indexing column in Sites - All Sites, the site status, privacy settings in Settings - Reading, and the post type. If the site is excluded or asks search engines not to index it, start there.

Global output is empty, but statistics are populated

Symptom: Post Indexer shows data, but the public page of recent posts displays nothing. That usually points to an issue with the compatible plugin, shortcode, or template. Check the shortcode syntax, post limit, post type, page cache, and whether the output is running on the network main site.

Rebuild takes too long

Symptom: the network crawl takes a long time or puts noticeable load on the server. Reduce the number of post types, exclude nonessential sites, shorten the index depth, and run the crawl in smaller batches. On a large network, a full index of all pages and custom types may be excessive if all you need is a simple feed of new content.

Errors appeared after an update or migration

Symptom: after a site migration, PHP update, or environment change, the index stopped updating. Check that the plugin tables still exist, that the WordPress scheduler is running, and that the plugin code matches the current archive from a trusted source. For older versions, be sure to account for published security fixes.

Quick troubleshooting path

Check	What should be true	What to do if it fails
Publication	The post is published on an approved site.	Rule out drafts, private content, and the wrong post type.
Site settings	The site is not disabled in the indexing column.	Enable indexing or rebuild only this site.
Statistics	You can see post count growth and recent content.	Check the tables, scheduler, and index rebuild process.
Public output	The list reads the index and shows original links.	Check the shortcode, cache, template, and settings of the connected output plugin.

SEO, performance, and security for a network-wide index

A network-wide index affects more than admin convenience. It can change which content becomes visible on the main site, how search engines discover links between subsites, and how heavy the database queries become. That is why Post Indexer settings should be aligned with your SEO, performance, and access policies.

SEO without duplicating content

If you display excerpts from child-site posts on the main site, make sure the page works as a navigational showcase rather than a full copy of the content. It is better to show the title, a short excerpt, the date, the author, or the source site, and then link to the original. That way, the main site helps users discover content without turning into a duplicate of the entire network.

Cache and freshness

Page cache can hide a successful index update. If a post appears in Post Indexer statistics but not on the public page, clear the cache for that specific page and check the output while logged out. There is no need to disable all site caching without a reason: it is usually enough to exclude the global feed page from long cache lifetimes or reduce the cache duration.

A safe approach to older versions

Take published information about older vulnerable versions seriously. Do not install archives from questionable sources, do not enable outdated code on a live network, and do not leave a network plugin unmanaged. For a legacy product, safe operation starts with a staging copy and verification of where the files came from.

When Post Indexer is the right choice

Post Indexer is worth considering if you run WordPress Multisite, have a clear network indexing use case, and are prepared to test an older unsupported plugin carefully. It is useful when you need to collect publications from different subsites into a shared layer for global lists, older WPMU DEV integrations, or custom network functionality. For that kind of task, the plugin provides a foundation that ordinary single-site search cannot easily replace.

If, on the other hand, you need modern search, active support, and advanced relevance rules, it is better to compare Post Indexer with search-focused alternatives before installing it. For a live network, start with a staging copy, enable only the sites and post types you actually need, verify one new publication, and then carefully rebuild the older index. After that, you can download the Post Indexer file and test it in your own scenario without putting the primary site at risk.

The main idea is simple: this plugin works well when you need a shared Multisite index, not a universal magic search button. If you define in advance which sites and posts should enter the shared layer, Post Indexer becomes easier to configure, easier to verify, and easier to disable safely if it turns out not to fit your environment.