Laravel Search Across Multiple Content Types Without Leaking Draft Content

Once ICanUp had not only Posts but also Categories, News, and Tips, separate search experiences for each content type no longer made sense.

A user enters one query and expects to find everything relevant. On the server, however, that does not mean running the same LIKE condition across four tables and merging the results.

Each entity has its own visibility rules, localization rules, and explicitly searchable fields.

The most dangerous failure is not a missing result. It is exposing a Draft, scheduled item, or wrong-locale text that the public application is not supposed to reveal.

At the interface level, the architecture looks simple:

The server-side contract is different for every branch.

I therefore do not build one universal query that tries to interpret every entity identically.

Search orchestration is shared. Availability rules remain domain-specific.

Imagine that a normal Post detail page correctly checks publication status and publication time.

Search is implemented separately and looks only at translations:

If publication constraints are missing, a Draft can appear in Search while its direct URL correctly returns 404.

To the user, that is a non-public content leak. Architecturally, it means the application has two different answers to the question "is this Post public?".

The Post search contract is intentionally independent from Category feed visibility.

A Post can be returned when:

• status = published;
• published_at is not null;
• published_at <= now().

Category state does not accidentally hide the Post.

A published Post may have no Category, belong to an inactive Category, or belong to a Category with show_in_public_feed = false. If the Post itself is public, those Category properties do not change its Search contract.

For Posts, I search only text with real reader-facing meaning:

• current-locale title;
• current-locale short_text;
• current-locale public ContentBlock text.

I deliberately exclude:

• slug;
• Category fields;
• meta_title;
• meta_description;
• meta_keywords;
• translations from another locale.

Searching slugs or SEO metadata initially looks like a way to find more content.

It can also produce results whose matching text is completely invisible to the user.

For internal public search, I prefer another rule: a result should match text the reader can actually see or an explicitly defined meaningful relationship.

A Category has no published_at and should not inherit Post rules.

For Search, being active is enough:

show_in_public_feed is not a Search condition.

A Category also does not disappear from Search merely because it currently has no published Posts.

This is a good example of why an existing scope should not be reused mechanically simply because both features are described as public.

Visibility in the blog feed and discoverability of an active Category through Search answer different questions.

• name;
• short_text;
• description.

Again, there is no slug or SEO metadata matching.

News results are limited to content already eligible for public access.

This protects two separate cases.

A Draft should never appear. Scheduled News should not become searchable before published_at, even when its translation already exists in the database.

• current-locale title;
• current-locale excerpt;
• current-locale public ContentBlocks.

Slugs and SEO metadata do not act as hidden matching sources.

A Tip differs from Post and News in one more useful way.

Its meaning to the reader can come not only from Tip text but also from its Topic and Tags.

The public Tips search therefore includes:

• title;
• short_text;
• public ContentBlocks;
• topic.name;
• topic.short_text;
• tag.name.

Tags add a small but useful normalization rule.

A user may search for:

or:

The leading # is normalized so both inputs have the same search semantics.

This does not turn into slug matching. Search still targets the visible Tag name.

For a multilingual site, this is one of the most important boundaries.

The Ukrainian Search evaluates Ukrainian translations only. English Search evaluates English translations only.

I do not want Ukrainian Search to return a Post merely because a word exists in the English translation.

That creates an unexplained result: the user enters a term, cannot see it in the card, opens the Ukrainian page, and still cannot find why the result matched.

Fallback behavior can be useful in some interface scenarios, but public Search has different semantics. It answers the question: "where does this term exist in the language I am currently using?".

ContentBlocks introduced a separate problem.

Searchable text can live in Heading, Rich Text, FAQ, Cards, Steps, Code, lists, tables, or a future block type that does not exist yet.

Maintaining separate Search mapping for every block type would be fragile.

Instead, each ContentBlock has a derived search_text projection.

Its purpose is to contain only text that a reader can actually see.

HTML becomes plain text. Visible Code, FAQ, Cards, Steps, lists, and other textual content can participate.

Technical configuration should not.

• media IDs;
• URLs used only as configuration;
• target;
• variant;
• alignment;
• technical enum values;
• other rendering configuration.

This is an important architectural boundary.

search_text answers only "which visible text exists inside this block?".

It does not answer "is this block public right now?".

Posts, News, and Tips therefore search only through public ContentBlocks in the current locale.

An inactive or wrong-locale block may have valid search_text but still must not create a public result.

A derived search projection is useful only when it reflects current data.

Whenever a ContentBlock is saved through the normal Eloquent lifecycle, search_text is recalculated from its current data.

Historical blocks use the same extractor through a dedicated backfill operation.

Combining multiple sources creates another UX problem.

If a query matches the title, the reason is obvious. If it matches text deep inside a ContentBlock, Topic, or Tag, the normal card may not display that term at all.

Non-obvious matches therefore need a compact context row.

The ContentBlock snippet comes only from a public block in the current locale, is converted to plain text, and is limited to a short region around the match.

If the matching term is already visible in the title, name, short text, or excerpt, an extra "Found in text" line only adds noise.

Context is useful when the reason would otherwise be hidden.

If Search finds a term deep inside a long article, opening the top of the page is not enough.

The user should reach the specific ContentBlock.

The public renderer therefore needs a stable technical target for the block.

The Search URL adds a fragment to the normal public entity URL.

Another edge case appears when the matched text lives inside initially hidden content such as an FAQ answer or collapsible Code block.

Search should never navigate to a result whose matching text remains hidden and unexplained.

One Search aggregates several result types, but it should not invent another URL scheme.

Each result uses its normal public URL in the active locale.

The shared slug and existing localization layer remain the source of truth. Search only receives the correct destination.

Posts, News, and Tips already have public feed presentation.

Creating separate nearly identical Search cards would eventually cause drift between the two interfaces.

Search therefore reuses the shared public presentation layer and adds only search-specific context around it.

Category is different because it has no equivalent feed card.

Its compact result component can use:

• logo when available;
• optional image;
• localized name;
• appropriate public short text;
• graceful media fallback.

Search behavior should match normal user expectations.

Letter case should not change the result and meaningful substrings can match longer words.

This is one of the central architectural ideas behind the implementation.

I need one user-facing Search experience, but I do not need one giant query builder that understands every domain rule.

This makes it possible to add another searchable entity later without moving all of its domain semantics into one central query.

Once several content types share one result page, another risk appears: every result card can start loading translations, Media, Topics, or Tags individually.

Paginated Search therefore needs performance verification in addition to functional correctness.

• localized fields are loaded predictably;
• Media does not create one query per card;
• Tip Topic and Tags do not introduce N+1 queries;
• ContentBlock match context does not require one expensive query per result;
• pagination does not change visibility behavior.

Negative scenarios matter as much as positive ones.

It is not enough to prove that a published Post can be found by title. The test suite also needs to prove that non-public content cannot be found.

This small test protects the multilingual contract from an accidental orWhereHas that forgot the locale constraint.

• Do not search every entity with one identical set of rules.
• Do not duplicate visibility rules when the domain already has a public contract.
• Do not expose Draft or scheduled content because a translation already exists.
• Do not use another locale as a hidden fallback for Search.
• Do not search slugs merely to increase result count.
• Do not use SEO metadata as an invisible match source.
• Do not let search_text determine ContentBlock public visibility.
• Do not implement a separate extractor for every ContentBlock type.
• Do not build separate Search-only presentation for Posts, News, and Tips.
• Do not navigate to the top of a long page when the match belongs to a specific ContentBlock.

• Define public visibility separately for every searchable entity.
• Define explicit searchable fields for every entity.
• Search current-locale content only.
• Avoid SEO metadata and slugs as hidden match sources without a clear reason.
• Use one reusable visible-text projection for ContentBlocks.
• Keep visibility outside the search_text projection.
• Return understandable context for non-obvious matches.
• Navigate ContentBlock matches to the exact block.
• Reveal collapsed content before highlighting.
• Use the entity canonical public URL.
• Reuse existing public presentation components.
• Verify query count and N+1 behavior.
• Test Draft, scheduled, wrong-locale, and inactive-block scenarios negatively.

Combining Posts, Categories, News, and Tips into one Search UI was straightforward. The more important part was preserving the boundaries between those entities.

Post has its own status and published_at rules. Category only needs to be active and its show_in_public_feed flag does not control Search. News and Tips have their own publication and localization contracts, while Tips also add Topic and Tag matching.

For ContentBlocks, I avoided teaching Search about every block type. Visible text is projected once into search_text, while visibility and locale remain the responsibility of the public ContentBlock relation.

I also keep locale boundaries strict: Ukrainian Search does not search English content, and English Search does not search Ukrainian content. Otherwise the result may have no visible reason on the page the user opens.

My main conclusion is simple: one public search can combine many domain entities, but it should not combine their publication rules into one approximate condition.