Let’s start with a clear, plain-language definition before looking at specific fields.

The simple definition

Metadata fields are special, built-in fields that Elasticsearch automatically attaches to every document, describing facts about the document itself — such as which index it lives in, its unique identifier, and how many times it has been updated — rather than describing the actual business data the document represents. They’re easy to spot because their names all begin with an underscore, like _index or _id.

Understanding the distinction between “about the document” and “inside the document” clears up a lot of confusion.

A quick tour of the handful of metadata fields you’ll encounter most often.

Together, these two fields form a document’s complete address inside a cluster.

Every document has a home — the index it was stored in — and a unique identifier within that index. Together, the _index and _id values act like a full mailing address: the index is the city, and the ID is the street address within it. This combination is exactly what Elasticsearch uses whenever you ask it to fetch, update, or delete one specific document directly, rather than searching for it.

When to choose your own ID

Providing your own meaningful ID — like an existing order number or user ID from another system — makes it simple to update or overwrite the exact same document later, rather than accidentally creating duplicates.

The field that quietly makes it possible to get your original document back exactly as you sent it.

When Elasticsearch indexes a document, it doesn’t just break it apart into searchable pieces and throw away the original — it also keeps a complete, untouched copy of the original JSON you submitted, stored under _source. This is what gets returned whenever you retrieve or search for a document, letting you see the full, original data rather than just the internal search structures.

A quiet counter that prevents two updates from silently overwriting each other.

Every time a document is created or updated, its _version number increases by one. This might seem like a minor detail, but it becomes essential when two different processes try to update the same document around the same time — the version number lets Elasticsearch detect that a conflict may have occurred and respond accordingly, rather than silently letting one update overwrite the other without anyone noticing.

sequenceDiagram
    participant AppA as Application A
    participant ES as Elasticsearch
    participant AppB as Application B
    AppA->>ES: Read document (version 3)
    AppB->>ES: Read document (version 3)
    AppA->>ES: Update document (expects version 3)
    ES-->>AppA: Success, now version 4
    AppB->>ES: Update document (still expects version 3)
    ES-->>AppB: Conflict detected — version is now 4
        

This one only shows up during searches, and it answers a very specific question: how good is this match?

Unlike _index or _id, which exist for every stored document, _score only appears in search results. It’s a number representing how relevant Elasticsearch judged that particular document to be for the specific search query you ran — higher generally means a stronger match. This is exactly what lets Elasticsearch sort results by relevance, showing the most useful matches first.

Following one document from creation to search to see when each metadata field comes into play.

Automatic metadata saves effort, but it’s worth understanding what you’re trading away.

A couple of these fields deserve careful thought when sensitive data is involved.

A few things worth watching as a reflection of how metadata fields are behaving at scale.

A few lessons worth learning from before they cause problems in production.

Simple habits that avoid the most common metadata-related mistakes.

Metadata fields quietly support everyday systems people interact with constantly.

The underscore-prefixed metadata fields are reserved and managed by Elasticsearch itself. If you want to store your own descriptive information about a document, it should be added as a regular field within the document body instead.

No. A score only exists in the context of a search result — a document sitting in storage, not part of any active search, doesn’t carry a score.

You save on storage space, but you lose the ability to retrieve the original document as it was submitted, and certain operations that rely on reading the original data, like reindexing, become unavailable.

No — an _id only needs to be unique within its own index. The same ID value can exist in two different indices without conflict, since _index and _id together form the true unique address.

Even in simple applications, version tracking is a useful safety net, and some features — like certain safe update operations — rely on it working correctly behind the scenes, whether or not you ever check it directly.

Metadata fields are the quiet, automatically-managed labels Elasticsearch attaches to every document — describing where it lives, what identifies it, what its original content was, how many times it has changed, and, during a search, how relevant it is. You rarely need to set them yourself, but understanding what each one does — and the trade-offs tied to fields like _source and _id — helps you design applications that avoid duplicate data, protect sensitive information, and handle concurrent updates safely.