Candidate Indexing: Keywords, Phrases, Entities & Chunks

Candidate indexing is the layer that turns raw indexed pages into structured, rankable signals. Before StretchSearch can rank anything or ground an AI answer, it extracts candidates — keywords, phrases, entities, and content chunks — from your pages. This article explains what those candidates are and how to inspect them.

Why candidates exist

A crawled page is just text and metadata. To make it searchable and rankable, StretchSearch breaks it into deterministic, inspectable pieces:

• Sources — the indexed pages that candidates were derived from, with their URLs and content hashes.
• Page chunks — the page split into coherent passages, each addressable for retrieval and citation.
• Keyword candidates — single significant terms, with normalized forms and frequencies.
• Phrase candidates — multi-word phrases (weighted higher than single keywords).
• Entity candidates — recognized named things (people, brands, products), weighted highest.
• Chunk references — pointers that tie candidates back to the exact chunk they came from.

Inspect the candidate overview

1. Open the Candidate indexing view (part of StretchSearch's observability surface).
2. The overview summarizes what's been indexed for the scope you choose — by project, crawl job, page, source URL, or content hash.
3. Drill into sources, page chunks, keywords, phrases, entities, or chunk references to see the underlying records.

Filter candidates

Every candidate view accepts the same filters, so you can narrow to exactly what you need:

• Project or crawl job — scope to an engagement or a single crawl.
• Page, source URL, or normalized URL — focus on one page.
• Content hash / snapshot hash — pin to a specific captured version of a page.
• Term — search within candidate labels.
• Limit and offset — page through large result sets (up to 500 at a time).

How candidates feed the rest of the product

Candidate indexing is the raw material for two downstream features:

• Ranking previews — the StretchRank engine scores keyword, phrase, entity, and chunk-reference candidates to produce ordered previews (see Understanding Evidence Ranking Previews).
• Retrieval & the AI bridge — page chunks become the evidence chunks returned for a query and bundled into evidence packages for AI grounding.

Because extraction is deterministic, the same page snapshot always yields the same candidates — essential for reproducible ranking and defensible citations.

A realistic example

An analyst wants to know how strongly Northwind's site associates with "single-origin espresso." They open candidate indexing, filter to the Northwind Coffee — Q3 SEO project, and search the phrase in the phrases view. They see the phrase candidate with its frequency across pages, then jump to chunk references to find the exact passages it appears in — evidence they can cite in the audit.

Tips

• Filter by content hash when you need to compare candidates across two captures of the same page — it isolates a single version.
• Entities and phrases carry more ranking weight than bare keywords; when auditing topical authority, start there.
• Use term search inside a candidate type to quickly confirm whether a target keyword is even present on the site.
• Page through large sets with limit/offset rather than trying to load everything at once.

FAQ

Is candidate indexing something I trigger? It's part of StretchSearch's governed indexing pipeline and observability surface. As a workspace user you primarily inspect candidates; generation runs as part of the platform's indexing flow.

Why are there no candidates for my project? Candidates come from indexed pages. If nothing has been indexed for the scope yet, the candidate views will be empty.

What's the difference between a keyword and a phrase candidate? A keyword is a single significant term; a phrase is a multi-word expression. Phrases (and entities) are weighted higher in ranking because they're more specific.