Result cards control how individual search results are displayed.

Use result cards when you want different result types to show different information. For example, a Programs result might show a thumbnail, credential, delivery mode, and study area, while a News result might show a date, topic, and shorter summary.

Open Search Configuration > Result Cards to create and edit result cards.

What a Result Card Controls

A result card can control:

Most services start with the default result card and add more cards only when different scopes or categories need noticeably different presentation.

Built-In Layouts

Choose a built-in layout when you want a supported card design without custom structure.

Changing between built-in layouts is a display change. It usually does not require reprocessing or reindexing.

The Classic search result layout can show a site, organisation, or department name when a suitable indexed field exists, such as site_name, site_title, organisation, organization, or department. If no such field exists, the card still shows the URL path above the title.

Custom Layouts

Choose Custom layout when a result card needs a customer-specific structure.

After choosing Custom layout, click Customize layout to open the layout builder. The builder lets you arrange safe structured blocks rather than writing raw HTML, CSS, or JavaScript.

Layout builder controls

At the top of the builder you can set:

Each block row in the builder exposes only the options that apply to that block type. You can reorder blocks by dragging the handle on the left.

Block types

Common block types include:

Custom layouts are designed to be safe and maintainable. They can use indexed fields and standard presentation options, but they do not allow raw script or style code.

The base setting in a custom layout is reserved for compatibility with the built-in card catalogue. It is validated and preserved, but custom layouts are rendered from their explicit block list rather than inheriting a built-in layout's internal markup.

Options by block type

Presentation options

Display modes

If you do not set a separator, text and inline use ; between values.

Overflow handling

When a field has more values than Limit allows:

Tone controls visual emphasis. Use primary for the most important evidence, secondary for supporting detail, and muted for de-emphasised context such as provenance or category labels.

Hide if empty removes a field or field-group block entirely when the indexed value is missing. This keeps cards tidy when enrichment is partial.

Show page type on a title block adds the result's category beneath the title. Turn this off when badges or a dedicated field already show the category.

Highlight query matches

Highlight query matches is available on Single metadata field blocks in the layout builder. Turn it on when the field is already shown on the card and you want visitors to see which values relate to their current query.

What visitors see:

Requirements and limits:

• The field must be a text Search Field. Keyword fields cannot use this option.
• Emphasis reflects literal query highlights from Elasticsearch. It is not a full explanation of hybrid, semantic, or vector ranking.
• Enabling or disabling the option on an existing indexed text field does not require reindexing.
• Brand-specific colours for matched chips can be tuned in the service style.css (for example, overriding .hit-block-chip--matched). See UI Design.

Good uses:

• Skills, topics, tags, expertise phrases, or product attributes already shown as chips
• Any visible text field where repeating the same text in a separate accordion would feel redundant

Avoid claiming that highlighted terms are the only reason a result ranked highly.

Action links

Action blocks render a single safe link per result.

Match evidence

Match evidence blocks add a native accordion to the card. The accordion is usually closed by default so result cards remain easy to scan.

The block reads highlighted fragments from selected text fields for the visitor's current query. If none of the selected fields produces a highlighted fragment, the accordion is hidden when Hide if empty is enabled.

Use match evidence when useful evidence comes from fields that are not already visible on the card, such as publication titles, long descriptions, transcripts, or hidden evidence text. For fields that are already shown (for example expertise or topic chips), prefer Highlight query matches so the card does not repeat the same information.

Match evidence is for explainability, not ranking claims. Avoid labels that imply the system has confirmed affiliation, seniority, or quality unless that data is explicitly indexed. Enabling match evidence on existing indexed text fields does not require reindexing.

Choosing between highlight matches and match evidence

Example custom layout

This pattern works well for profile-style results with topic chips, inline metadata, and footer badges. Visible chips use Highlight query matches; the accordion is reserved for supporting text that is not already on the card.

For program-style cards, a Metadata field group with columns: 3 is a good way to show related facts (for example degree, delivery, and location) in one block:

{
  "layout": "custom",
  "badges": [
    { "attribute": "match_rating", "icon": "star", "tone": "primary" },
    { "attribute": "source_type", "icon": "tag", "tone": "muted" }
  ],
  "layout_config": {
    "version": 1,
    "base": "media_card",
    "image": { "position": "right", "aspect_ratio": "4:3", "show_if_empty": false },
    "blocks": [
      { "type": "title", "show_page_type": false },
      {
        "type": "field_group",
        "attributes": ["degree", "delivery", "location"],
        "columns": 3,
        "tone": "secondary",
        "hide_if_empty": true
      },
      {
        "type": "field",
        "attribute": "expertise",
        "label": "Expertise",
        "display": "chips",
        "max_items": 8,
        "overflow": "count",
        "tone": "primary",
        "highlight_matches": true,
        "hide_if_empty": true
      },
      {
        "type": "field",
        "attribute": "fingerprint_topics",
        "label": "Topics",
        "display": "chips",
        "max_items": 5,
        "overflow": "count",
        "tone": "secondary",
        "highlight_matches": true,
        "hide_if_empty": true
      },
      {
        "type": "field",
        "attribute": "for_labels",
        "label": "Fields of Research",
        "display": "inline",
        "max_items": 3,
        "separator": " · ",
        "overflow": "count",
        "tone": "muted",
        "hide_if_empty": true
      },
      { "type": "badges" },
      {
        "type": "match_evidence",
        "label": "Why this result matched your search",
        "source_attributes": ["representative_titles", "evidence"],
        "max_fragments": 3,
        "max_length": 280,
        "default_open": false,
        "hide_if_empty": true,
        "tone": "muted"
      }
    ]
  }
}

Adding a new field block usually requires reprocessing or reindexing so the field values exist in the search index. Changing display options, limits, tones, Highlight query matches, match-evidence settings, or block order does not.

Field Badges

Field badges are short indexed field values shown on a result card to help visitors scan results quickly.

Examples:

• Credential: Certificate, Diploma, Degree
• Delivery: Online, In person, Blended
• Format: Full-time, Part-time
• Date: 12 May 2026
• Document type: PDF, Guide, Policy

Badges are based on indexed Search Fields. If a field has no value on a result, the badge can be hidden or can show a fallback label, depending on the badge settings.

Badge options

Use badges for useful, compact facts. Avoid adding too many badges, because a crowded result card is harder to scan.

On custom-layout cards, place a Badges block where you want the badge row to appear. Badge tone is especially useful for separating strong signals (such as match strength) from quieter provenance labels.

Advanced Bindings

Advanced bindings control which indexed values feed the main result card fields.

For most result cards, leave these unchanged:

• Title usually comes from title.
• URL usually comes from URL.
• Summary usually comes from description or the generated result snippet.
• Image usually comes from image.

Change advanced bindings only when a service has reliable custom fields that should replace the standard values. For example, a program card might use a dedicated program title field if the normal page title contains extra website navigation text.

Assigning Result Cards

Result cards can be assigned in two places: Category Result Cards on the Result Cards tab, and per-scope cards on the Scopes tab.

Category result cards

Use Category Result Cards at the top of the Result Cards tab when mixed result sets need different cards per category.

This matters most for the All Results scope and any other view that returns more than one category at once. Each row maps one category value to the card that should render matching hits.

Example:

When a hit matches a configured category value, that card is used even if the active scope has a different default card. Scope-level cards still apply when no category mapping matches the hit.

After saving category mappings, test from the All scope to confirm each category renders with the intended card.

Scope result cards

Assign a default card per scope from Search Configuration > Scopes.

Each scope can use a different card. After saving a new result card, scope and category dropdowns refresh automatically when you switch tabs.

For example:

Use separate cards when different result types need different visual treatment or metadata. Keep one shared card when the result types are similar.

When both category mappings and scope cards exist:

1. Category mapping wins for hits that match a configured category value in mixed result sets.
2. Scope card is used when no category mapping applies, or when the scope filters to a single category.

Service styling

Result cards use Airgentic's built-in search CSS. For brand-specific spacing, colours, chip styling, or typography beyond what the layout builder provides, add scoped rules to the service style.css file on UI Design.

Use stable selectors such as .hit-card, .hit-block, and .preview-hit-metadata-item. See UI Design for the supported class contract and override order.

Layout and badge changes in Search Configuration do not require CSS changes. CSS is optional polish when you need finer visual control than the descriptor options allow.

Testing Result Cards

Use the preview inside the Result Cards tab to check one card at a time.

Use Search Configuration > Preview to test the full saved search experience, including scope tabs, filters, sorting, and result cards together.

When testing:

1. Try a query that returns the intended result type.
2. Confirm the title, summary, image, and badges are populated.
3. Check empty states, such as results without images or missing badge values.
4. For custom layouts, confirm field blocks respect Hide if empty, chip limits, and +N more overflow.
5. If Highlight query matches is enabled, search for a term that appears in a chip or field value and confirm matching chips or words are emphasised without truncating or joining words incorrectly.
6. If Match evidence is enabled, confirm the accordion opens and closes, shows only non-duplicative evidence, and hides when no highlights are available.
7. Click action links and confirm they open the expected result URL.
8. If using expand overflow, open and close the Show more control with keyboard and screen reader where possible.
9. Test mobile width if the card uses images, chips, or several badges.
10. Save the card, then test it in the scope where it is assigned.
11. For category mappings, run a mixed query from All and confirm each category uses the right card.

Changing a card layout, badge label, presentation option, category mapping, or scope assignment usually does not require reindexing. Enabling Highlight query matches or Match evidence on existing text fields also does not require reindexing. Adding a new field for a badge or custom layout block usually requires reprocessing or reindexing so the field values exist in the search index.

Related Guides

• Configuring Indexed Fields
• Configuring Filters
• Configuring Search Scopes
• Testing and Previewing Site Search
• UI Design