Site search on Core dna is an Elasticsearch index that the platform fills and queries, and a page you build. What reaches the index, search views, the search page, product facets, filtered listings that need no index, and when to go beyond the built-in index.
L2
Unit 01 · Indexing and search views
Why a new record is not findable yet
Indexing and search viewsPage 5 of 20Updated
Indexing runs in the background, so a record published a moment ago may not be found yet. How long the delay is, a sentence to give the client, the request that tells a delay from a misconfiguration, and the causes in the order to check them.
Who this is for. The developer answering "I published it and search cannot find it", and the one explaining the delay to a client. Afterwards you can tell in one request whether a record is late or will never arrive, and why.
What happens between publish and searchable
Saving a record does not write to the index. It starts a chain of background steps, each of which waits its turn in the platform's queue:
The save, made in the admin or through the API, queues a record event.
A worker handles the event: it starts any jobs that listen for it, writes the audit log entry, and queues an indexing job for each index that takes the record type.
A search worker loads the record as a signed-out visitor would, builds its document, or decides it should no longer be indexed, and writes the change to Elasticsearch. A failed write is tried up to five times in all, 30 seconds apart.
Elasticsearch makes the change searchable at its next refresh, normally within a second.
On a quiet site the chain takes seconds. While the queue is busy, during a reindex, a large import or a long job run, it can take minutes.
A record published with a date in the future has no save at that moment to start the chain. A platform task that runs once a minute for each site finds the records whose publish date has passed since its last run and queues the same event for them, so they become searchable within a minute or two of going live. It covers pages, blogs, blog posts, FAQ questions and product descriptions, and books, units and book pages on releases after 2026.8.1. The same task takes out pages (and, on those releases, books) whose unpublish date arrives.
What to tell the client
"New and changed content appears in site search within a minute or two of going live. During a full reindex or a large import it can take longer. Content that only signed-in members can see never appears in site search."
Telling a delay from a misconfiguration
Ask the index for the one record, by its type and its id, with no query. If the view lets visitors change the entityClass and id filters, which it does unless someone switched their Changeable off, the answer holds the record once it is indexed. The same parameters work on the search page's own URL, /search/<view slug>?entityClass=Pages%5CEntities%5CPage&id=1881, requested with Accept: application/json.
One record's document, asked for by type and id
GET /cdna-api/search/hub-docs-search?entityClass=Pages\Entities\Page&id=1881 HTTP/1.1
Host: hub.coredna.com
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json
indexed is when the document was last written, in UTC; a template reads it with $item->getDate('indexed'), in the site's timezone. Compare it with the time of your change. If the record is missing after a few minutes, or present with an indexed time before your change, it is not a delay: work through the causes below. A totalCount of 0 for a record you can open in a private window narrows it to causes 2, 4, 5, 7 and 8.
Causes, in the order to check them
Not published, or its published date is still in the future.
Robots settings on the record's SEO set to Don't index, but follow or Don't index and don't follow. Either takes it out of site search, not only out of search engines.
Not readable by a signed-out visitor. The record is restricted to a group, or the module's default read privilege does not include the public. Open the record's URL in a private window: if it is not there for you, it is not there for the indexer.
A type the index does not take: a custom entity record, an FAQ page rather than its questions, or a book page on a site at release 2026.8.1 or earlier (What gets indexed).
Saved by a background process. A save made outside a web request, by an asynchronous or scheduled job, an import or a script run on the server, queues no record event, so nothing indexes it. Change and save it once in the admin (a save that changes nothing may not count), or run Reindex.
Found by its title but not by its words. The areas holding the words are not mapped to a search field, or the field is not among the view's full text search fields (Search fields).
Filtered out by the view: a fixed record type, category or language on the view leaves it out, whatever the query.
Nothing new is indexed on that environment at all. Every recent record is missing, and old ones show an old indexed. The background indexing workers are not running there, or the index was built from another copy of the database. Run Reindex; if new records still do not appear, ask Core dna to check the search workers for that environment.
Imports and asynchronous jobs do not index what they write
A record written by an asynchronous job, a scheduled job or a server-side import fires no record event, so it is not indexed, and the jobs that listen for record events do not run for it either. Plan a Reindex after any bulk write that does not go through the admin or the API in a web request (What leaves the index stale).