Understanding Apps, Languages, and Search Profiles

SearchStax Site Search is organized around three core objects: Apps, Languages, and Search Profiles. This article explains what each object does, how they relate, and how search requests flow through the hierarchy.

What Each Object Is For

Apps: Top-Level Environment Container

An App is the top-level container for your search environment. It contains one index that all Languages and Profiles in that App share.

Use Apps for environment-wide settings and resources:

  • API endpoints and API access tokens
  • Dashboard access controls
  • Data sources and indexed content
  • Web crawlers

Create separate Apps when you need separation by team ownership or environment such as Development, QA, and Production. You can also separate by brand when that is the cleanest operational boundary.

Note: One App can also support multiple brands when the brands share the same indexed content and governance model. In those cases, use Data Filters and distinct Search Profiles to create separate search experiences.

Languages: Language-Specific Behavior Inside an App

Languages are an optional App-level feature for multilingual search experiences.

Each Language has:

  • its own analytics database
  • its own set of Search Profiles, including a Default Profile
  • language-specific Synonyms and Stopwords dictionaries

All Languages in the App still share the same underlying index. Use Language-specific configuration and Data Filters together when you need to exclude content outside the desired Language.

Search Profiles: Experience-Level Configuration

A Search Profile is a named set of search settings. Use profiles to create different search experiences from shared indexed content by combining configuration choices with Data Filters.

At the profile level, you tune each experience with settings such as Search Fields, Ranking, Promotions, Rules, Results Fields, Facets, Sorting, Smart Answers, and Data Filters.

Each Language has one Default Profile and can have additional Profiles for specific audiences, sections, or use cases.

Example: a university can use one profile for Course Catalog searches and another for Campus Resources searches while still using the same App and index.

Hierarchy and Inheritance

The hierarchy is:

App -> Language -> Search Profile

  • App-level resources are shared across all Languages and Profiles in that App.
  • Language-specific behavior is applied within a selected Language.
  • Profile-level tuning determines what a particular search experience returns and how results are presented.

Defaults: Default Language and Default Profile

Default Language

One Language in an App is designated as the default. If a search request does not specify a Language, Site Search uses the default Language.

Default Profile

Each Language includes a Default Profile that is created automatically and cannot be deleted.

Note: Use the model parameter to select a profile in search requests. If you omit model, Site Search uses the default profile for the selected Language.

How Search Requests Flow Through App, Language, and Profile

When a user searches, your search UI sends a request to the Search API endpoint for the App. The request uses a selected Language, or falls back to the default Language, and it uses a selected profile through the model parameter.

The selected Profile applies Data Filters, Search Fields, Ranking, Promotions, Rules, and display settings to produce results.

Example: Northbridge University

Northbridge uses one Production App with two Languages: en and fr_ca. Each Language includes these Profiles:

  • University Search (default)
  • Programs and Admissions
  • Faculty Research

For a query like statistics, the App determines the available indexed content, the selected Language controls language-specific behavior and analytics, and the selected Profile controls filtering and ranking behavior.

For example, Programs and Admissions can be filtered to show only admissions and program content, while Faculty Research can prioritize research-related results and profile-specific facets.

When to Create a New App vs. Language vs. Profile

  • Create a new App when you need environment isolation, separate teams or access controls, or fully separate brands and organizations.
  • Add a Language when the same App and index must serve multiple languages with language-specific behavior and analytics.
  • Add a Profile when you need multiple search experiences from the same indexed content, such as admissions search versus research search.

Tip: Start with one App. First, use Languages, Search Profiles, and Data Filters to separate search experiences inside that App. Create additional Apps only when you need hard separation for security or for separate environments such as Development, QA, and Production.

Related Articles

Articles in this section