Improving WordPress search becomes a different kind of project when users need to search not only pages and posts, but also the full text of PDFs hosted on another web property. In one search-discovery project, users were frustrated enough with the site’s internal search that they often preferred using Google to find pages and documents.
Freshy reviewed the existing search stack and compared two directions: improving WordPress-native search with tools such as Relevanssi, or using a dedicated search platform such as Algolia. The deciding requirement was full-text search across externally hosted PDFs. The discovery concluded that a dedicated external index was the cleaner architecture. As requirements expanded, Freshy recommended validating the approach through an Algolia proof of concept capped at 20 hours before authorizing a larger production implementation.
Issue background
A content-heavy WordPress site had a recurring user-experience problem: visitors struggled to find the right pages and documents through the built-in search experience.
The complaint was not simply that search looked outdated. Users felt that relevance was poor enough that an external search engine often returned better results than the site itself.
The organization wanted to understand two possible directions:
- A more intelligent, Google-style search experience.
- A more traditional advanced search with keyword search, filters, sorting, and refinements.
An AI or chatbot interface was also discussed, but Freshy treated that as a possible future layer rather than assuming that conversational AI was required to solve the immediate information-discovery problem.
Diagnosis
Freshy first reviewed the existing WordPress search setup.
The live site had Ivory Search active and Relevanssi installed but inactive.
Those tools could improve WordPress-side search, but the most important content requirement lived outside WordPress: a large collection of PDFs on a separate public web property.
The client clarified that users needed to search the contents of those PDFs, not merely their filenames, attachment titles, or links.
That requirement changed the architecture.
Ivory Search could search attachment metadata for files managed by WordPress, but it was not a clean solution for full-text indexing of arbitrary remote PDFs.
Relevanssi Premium can index PDF contents when those documents exist as WordPress attachments, but it does not natively provide a clean full-text index for arbitrary PDF files hosted on another site.
A dedicated search platform such as Algolia could instead crawl and index multiple approved web properties, including text-extractable PDFs.
Freshy therefore concluded that the external PDF requirement strongly favored a dedicated search index rather than extending the existing WordPress-only search stack.
There was still an important limitation: scanned, image-only, or unusually complex PDFs may require OCR or remediation before their contents can be indexed reliably.
Resolution steps
The documented discovery process evolved through several stages:
- Separate the search problem from the chatbot question. Freshy treated better information retrieval as the primary requirement, with conversational search as a possible future phase.
- Review the current WordPress search tools. Ivory Search was active, while Relevanssi was available but inactive.
- Compare a WordPress-native path with a dedicated search service. Enhancing Relevanssi could improve relevance for WordPress content, while Algolia offered a broader cross-property indexing model.
- Validate external PDF requirements. The client confirmed that full-text searching of remote PDFs was a core requirement.
- Recommend a dedicated external index. Algolia became the preferred direction because it could index approved content across multiple properties and include text-extractable PDFs.
- Define a proof of concept instead of jumping directly to production. Freshy recommended proving the difficult cases before committing to a full implementation.
- Refine the PDF-governance rule. The client did not want every file on the external document server indexed. The desired model became: approved current pages identify eligible linked documents, only those linked documents enter the search index, and documents should be removed from the index when they are no longer linked from approved content.
- Expand the POC to reflect real search behavior. The proposed proof of concept needed to demonstrate cross-property results, full-text PDF search, exclusion of an unlinked PDF, terminology aliases, acronyms, typo tolerance, current content outranking obsolete versions, content-type labeling, and search/click analytics.
- Identify likely custom ingestion work. Algolia could handle much of the crawling and indexing, but Freshy did not assume the crawler alone could manage the complete linked-document lifecycle. A lightweight ingestion or synchronization layer might be required.
- Keep authenticated content as a separate architectural question. Member-only systems introduced additional permission and authentication questions that needed more discovery.
The client and Freshy aligned on a proof of concept capped at 20 hours unless additional time was approved.
The POC was expected to deliver:
- A working demonstration of the agreed search scenarios.
- Validation of cross-domain indexing.
- Validation that linked external PDFs could be included while unlinked documents stayed excluded.
- Full-text PDF results using representative documents.
- Initial relevance tuning for acronyms, synonyms, misspellings, and current-versus-obsolete content.
- Confirmation that search and click analytics could be captured.
- A recommended production architecture.
- A list of remaining dependencies, risks, and technical unknowns.
- A preliminary Algolia usage and cost projection based on the actual index.
For testing, Freshy recommended a smaller representative query set during the POC rather than building the full production acceptance suite immediately. The larger production phase could later expand this into a structured set of roughly 100–150 queries.
Final outcome
The discovery did not result in a live search replacement. Instead, it produced a clearer architecture and a staged implementation plan.
The main conclusion was that improving WordPress-only search would not cleanly satisfy the requirement to search the full contents of externally hosted PDFs. A dedicated search platform such as Algolia was the stronger technical direction.
The scope also grew beyond a simple site-search replacement. The desired production system would eventually need to address cross-property indexing, selective document eligibility, PDF extraction, duplicate and canonical handling, current-versus-obsolete content, synonyms and acronyms, autocomplete, analytics, accessibility, and possibly authenticated content.
Because of those unknowns, Freshy recommended completing the POC first and then revisiting the production estimate. The preliminary production ballpark was approximately 45–60 hours, but the source task explicitly treated that as provisional until the POC answered the remaining architecture questions.
The broader lesson is that search technology should be selected based on the real content boundary, not just the CMS. If important information lives in remote PDFs, separate applications, or other web properties, improving the WordPress search plugin alone may never solve the user’s actual problem.
If your WordPress search needs to include external PDFs, multiple web properties, or more sophisticated relevance and analytics, contact Freshy. Our WordPress team can audit the content sources, compare search architectures, and design a proof of concept before committing to a larger implementation.
