Copy update to readme for clarity

Based on feedback from non-native English-speaking customers relying heavily on App Search in production, I've updated this text to be more explicit. The previous wording confused whether reindexing was optional during migration, so I've clarified the strong recommendation to reindex data.

notebooks/enterprise-search/app-search-engine-exporter.ipynb

@@ -213,9 +213,9 @@
    "source": [
     "## Create a new Elasticsearch index\n",
     "\n",
-    "While we could re-use the same Elasticsearch index that is storing the App Search engine documents, reindexing the data in a new index will allow us to change the mapping to use features like semantic search or to be able to use the Elasticsearch synonym set we just created.\n",
+    "We recommend reindexing your App Search engine data into a new Elasticsearch index instead of reusing the existing one. This allows you to update the index mapping to take advantage of modern features like semantic search and the newly created Elasticsearch synonym set.\n",
     "\n",
-    "App Search has the following data types: text, number, date and geolocation. Each of these types is mapped to Elasticsearch field types.\n",
+    "App Search has the following data types: `text`, `number`, `date` and `geolocation`. Each of these types is mapped to Elasticsearch field types.\n",
     "We can take a closer look at how App Search field types are mapped to Elasticsearch fields, by using the [`GET mapping API`](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-get-mapping.html).\n",
     "For App Search engines, the associated Elasticsearch index name is `.ent-search-engine-documents-[ENGINE_NAME]`, e.g. `.ent-search-engine-documents-national-parks-demo` for the App Search sample engine `national-parks-demo`.\n",
     "One thing to notice is how App Search uses [multi-fields](https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-fields.html) in Elasticsearch that allow for quickly changing the field type in App Search without requiring reindexing by creating subfields for each type of supported field:\n",