When a post is missing from search results, first establish whether its text is missing from the Relevanssi index or whether the search is filtering an indexed post out. The current Debugging tab provides tools for this without adding code to your theme.
Start with the saved indexing rules
Open Relevanssi > Settings > Indexing. Check that the relevant post type and any required custom fields or taxonomies are selected. Save changes before rebuilding the index.
Build the index replaces the existing index using your saved rules. Index unindexed posts resumes indexing posts missing from the index; it does not update already indexed posts after a change to their indexing rules. Do not repeatedly rebuild before establishing what is missing.
Find the post ID
Open the post’s editing screen and look at its URL. In post.php?post=123&action=edit, the ID is 123. Use the post’s ID rather than the page number or a taxonomy ID.
Inspect the saved search terms
- Open the Debugging tab.
- Under Inspect how Relevanssi reads your content, enter the post ID in Item ID.
- In Premium, choose Post or Page under Content Type for a post, page, product, or other post type.
- Click Analyze Content and inspect the displayed terms.
This view reads the terms currently stored in the Relevanssi index, grouped by their source, such as title, content, or custom fields. It is not a new simulation of how the latest version of the post would be indexed. If you changed the post or its indexing settings without refreshing its index entry, this view can still reflect the older entry.
If a recorded reason explains why the post was not indexed, the tool can display it. If it finds no entry, check the ID and exclusions; an empty view alone does not identify the cause.
Compare the original WordPress content
In Check how the post content appears in the wp_posts database, enter the same ID and click Examine Database Entry. This displays the post’s original post_content from WordPress, including stored HTML or shortcodes. It does not display the Relevanssi index or all post metadata.
Compare this with Analyze Content. If a page builder stores text only in custom fields, it may be absent from the original post_content view. Check the relevant field values and the custom field indexing settings separately.
Interpret the findings
- Expected text is absent from the source: find where the theme or plugin actually stores it. A visible page can be assembled from custom fields, referenced objects, or other data.
- Source text exists but its words are absent from the index: check indexing selections, excluded posts, shortcode processing, minimum word length, stopwords, and custom indexing filters. Refresh the entry after correcting the cause.
- Expected terms exist in the index: investigate the search instead. Check post type restrictions, Respect exclude_from_search, access rules, and whether the search form actually uses Relevanssi.
- The post matches but its snippet is wrong: check Display & UI and the theme’s excerpt output. Snippet generation is a separate step from indexing.
For PDFs, check that attachment text was extracted into _relevanssi_pdf_content before investigating indexing. See Indexing and searching PDFs in WordPress.
Trace one indexing operation with WP-CLI (Premium)
For a detailed trace, Relevanssi Premium provides this WP-CLI command. Replace 123 with the post ID:
wp relevanssi index --post=123 --index_debug=true
The command reindexes that post and prints diagnostic information about the operation, including indexing queries. It is not a read-only inspection. Use it on staging when testing integrations or debugging code, and do not share diagnostic output containing private content or metadata publicly.
If WordPress is installed outside the current directory, add WP-CLI’s --path option. The Debugging tab remains the simpler starting point when command-line access is unavailable.
Background debugging and failed index builds
The Debugging tab also has Enable background debugging logs. Keep it disabled during ordinary operation; enable it temporarily when Relevanssi support asks you to collect diagnostic information, then disable it again. See the current release notes for the guidance on debugging mode.
If a bulk build stops or fails, collect the displayed error, the last affected post ID if available, and the relevant PHP or database error messages. The Database Indexing Query section shows the query used to select posts for indexing and the database’s max_allowed_packet value. Packet limits can matter for large posts or metadata, but a stopped build does not prove that this is the cause.
Report the plugin version, the affected post ID and type, the expected text source, and the results of Analyze Content and Examine Database Entry. This gives support a concrete starting point without installing a frontend debugging snippet that interrupts normal page requests.