Map new Elasticsearch string fields as keyword by default

Use an index template and a dynamic template to map new string fields as keyword, with clear boundaries for legacy versions and existing data.

Best practices
Log monitoring illustration

Use a dynamic template inside an index template to map newly detected string fields as keyword. This changes how matching new indices are created; it does not convert fields that already exist.

Configure a composable index template

For Elasticsearch 7.8 and later, run this in Kibana Dev Tools:

PUT _index_template/string_keyword_template
{
  "index_patterns": ["myapp-*"],
  "template": {
    "mappings": {
      "dynamic_templates": [
        {
          "strings_as_keywords": {
            "match_mapping_type": "string",
            "mapping": { "type": "keyword" }
          }
        }
      ]
    }
  }
}

New, dynamically detected string fields in matching indices receive a keyword mapping: useful for exact values, sorting, and aggregations. Explicit mappings take precedence. Date detection, and numeric detection if enabled, can classify a JSON string as another type before this rule applies. Disable those detection features only if that matches your data model.

Check competing index templates before deployment. Template selection and priority determine which definition creates the index; installing a template does not guarantee it wins every match.

Keep legacy syntax in its version boundary

Elasticsearch 2.x used "type": "string", "index": "not_analyzed". Elasticsearch 5 introduced text and keyword; do not label the old string syntax as a general Elasticsearch 6 configuration. Older index-template APIs also used a different request shape and mapping types. Use the documentation for that exact release when maintaining a legacy cluster.

Decide which fields still need full-text search

The usual dynamic mapping creates a text field with a .keyword subfield, serving both full-text and exact-value queries. Keep that arrangement for searchable prose. Use explicit keyword mappings for known identifiers rather than applying a blanket rule if only a few fields need it.

Changing an existing field's type normally requires a new index with the desired mapping and a reindex operation. Validate document counts and queries before switching aliases. Adding a new field mapping is a different operation and does not automatically populate values for old documents.

See Elastic's dynamic template guide and index template guide.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting