Web Modernization · Recommendation

Website Search and Unified Locator: a phased path through November

Date3 September 2026

StatusFor discussion

Prepared byAxelerant delivery team

Where we began

How both products were planned for November

Website Search

An evolution of the search experience running on padi.com today, with enhancements to how results are presented.

Unified Locator

The current locator, improved through the user experience rather than rebuilt as a new service.

Both were planned within the existing platform, which shaped the effort and the timeline we committed to.

How the picture developed

Discovery sharpened what good looks like, especially for search

Scope beyond padi.com A dedicated search service Ingestion from several systems Natural language queries Context-aware ranking Every supported language Fast, as-you-type Helpful zero-result outcomes Extensible over time

We think this is the right destination, and it is a healthy outcome of working through discovery together. It does change the shape of the build: each of these is a build in its own right, rather than configuration of what exists today.

Our read

The destination is right; building it well takes more time than November allows

Its own service. Search like this runs as a service in its own right, pulling content from several systems and answering queries across all of them.
Time with real queries. Relevance in each language improves once people are actually searching, and that takes a few cycles.
Room in the plan. The other November commitments stay as they are, and we want to protect them.

Search and the locator are at different stages, so we have looked at each separately.

The locator

The locator is further along, and we are confident in it

Assessment and planning are complete, and we have an implementation approach built on OpenSearch.
Two capabilities the briefs introduce — context-based search and handling of empty result sets — sit naturally with search rather than the locator.
We have treated them that way here, so the locator can proceed on the plan we shared at the readout.

Recommendation · padi.com search

Site search built on Drupal for November

What it delivers

A search results page, autocompletion, and faceted refinement — an improvement on the experience today.

What it does not yet do

Natural language understanding and context-aware ranking come later, with the dedicated search service.

It meets what padi.com needs at launch, with no new platform or integration risk in the critical window.

Recommendation · Unified Locator

The locator proceeds as planned, and stands the platform up

The locator plan itself is unchanged from the readout. What we did not cover then was the search technology underneath it, because the detailed design was still in progress.
That design has since landed on Amazon OpenSearch. The locator always needed a search index behind it; this names the one we recommend.
The one real change: we now propose running it as a shared service rather than inside the locator, so site search can use it too.

Platform · a change from our earlier recommendation

We are moving our recommendation from Algolia to OpenSearch

	Algolia	Amazon OpenSearch
Investment	Meaningful additional spend at PADI's scale	Materially lower running cost
November	Timeline pressure remains, whichever platform sits underneath	Locator ships, and the foundation goes live with it
Path forward	Capability arrives as one larger release	Capability added step by step, without replatforming
Operating model	Managed by the vendor	Indexing, tuning and operations sit with the team

We recommended Algolia during the earlier evaluation, and it remains a capable platform that may still be right in February. What changed is the November timeline — Algolia's investment would begin well ahead of the capability it enables, while OpenSearch lets the foundation ship alongside the locator.

Being clear with you

The trade-offs we are asking you to accept

Search on padi.com in November is an improvement on today, but not yet the experience described in the brief. The Drupal-based search is an interim step, replaced when the shared service takes over.
If February moves to Algolia, the OpenSearch setup does not migrate. The index configuration, ingestion and query layer would be rebuilt on the new platform rather than carried across.
What carries forward either way: how the data is structured and modelled, the content tagging behind it, and the results experience itself.
Indexing, relevance tuning and operations sit with the team rather than with a vendor, which we have planned for.

In return, November lands as committed, and the platform investment carries into February.

The next phase · February

A dedicated search release, with the platform choice made together

Path A · Algolia

Expand onto Algolia, or move search to it entirely. Indicative investment of USD 75k–150k.

Throwaway work: the OpenSearch index configuration, ingestion and query layer are rebuilt on Algolia rather than migrated. The data structures and content tagging behind them carry over.

Path B · Extend our own foundation

Build the fuller capability on the November search service. More engineering effort, but February gives us the room.

Throwaway work: none. Every part of the November build is extended rather than replaced.

In the February scope: search across PADI's properties, natural language understanding, context-aware ranking, per-language relevance reporting, and sponsored results. We are not asking for the platform decision now — February gives both paths a fair hearing, informed by real query data.

Next step

What we would like to confirm with you

padi.com search delivered on Drupal for November, as a first step.
Unified Locator delivered as planned, with OpenSearch stood up as a shared service.
A dedicated search release in February, with the platform decision taken together nearer the time.