Restructure Docs - Stage 4a (#2280)

* create Develop and Deploy tabs; move Operations; re-weight pages

* move capacity planning page; create section dropdown content

* added aliases to frontmatter

* update link references to new canonical links; maintain anchoring

* address remaining link issues and errors

* fix outlier tutorial reference issue

* Treat 'develop' and 'deploy' as a unified search space

* fix some frontmatter aliases

* add section header redirects

* fix 'Operations' redirect to go to 'Deploy' tab

* update redirects file for * pattern

* add :splat to redirect references

* Add wildcard to each entry in _redirects file

---------

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

qdrant-landing/content/documentation/search/low-latency-search.md

@@ -9,7 +9,7 @@ aliases:
 
 ## Scale Horizontally with Replicas
 
-Qdrant can be deployed in a [distributed configuration](/documentation/operations/distributed_deployment/). In distributed mode, multiple instances of Qdrant, called peers, operate as a single entity, called a cluster. Data is stored in [collections](/documentation/manage-data/collections/), which are divided into [shards](/documentation/operations/distributed_deployment/#sharding) that are distributed across the peers. Each shard can have multiple [replicas](/documentation/operations/distributed_deployment/#replication) for redundancy and load balancing. Because every replica of the same shard contains the same data, read requests can be distributed across replicas, reducing latency and increasing throughput.
+Qdrant can be deployed in a [distributed configuration](/documentation/distributed_deployment/). In distributed mode, multiple instances of Qdrant, called peers, operate as a single entity, called a cluster. Data is stored in [collections](/documentation/manage-data/collections/), which are divided into [shards](/documentation/distributed_deployment/#sharding) that are distributed across the peers. Each shard can have multiple [replicas](/documentation/distributed_deployment/#replication) for redundancy and load balancing. Because every replica of the same shard contains the same data, read requests can be distributed across replicas, reducing latency and increasing throughput.
 
 For example, a collection with three shards and a replication factor of two would have six total replicas (two replicas for each of the three shards). On a cluster with three peers, these replicas can be evenly distributed across the peers, with each peer hosting two replicas.
 
@@ -49,7 +49,7 @@ Search latency can vary depending on where the data is in this process. Querying
 
 If your application requires a consistently low search latency, set the [search parameter](/documentation/search/search/#search-api) `indexed_only` to `true`. With this setting enabled, search operations will only consider indexed data, ensuring more consistent and lower response times. The tradeoff is that the most recent data might not be included in search results until it has been indexed.
 
-Enabling `indexed_only` can cause recently updated data to temporarily disappear from search results until it is indexed again. To mitigate this, set the `prevent_unoptimized` optimizer setting to `true` when [creating or updating a collection](/documentation/manage-data/collections/#update-collection-parameters), or globally in the [configuration file](/documentation/operations/optimizer/). It prevents creating segments with a large amount of unindexed data for searches. Instead, once a segment reaches the so called `indexing_threshold`, all additional points will be added in 'deferred state'. Deferred points are not yet visible in reads but are still handled in writes. Deferred points will be promoted to visible points once the segment is optimized.
+Enabling `indexed_only` can cause recently updated data to temporarily disappear from search results until it is indexed again. To mitigate this, set the `prevent_unoptimized` optimizer setting to `true` when [creating or updating a collection](/documentation/manage-data/collections/#update-collection-parameters), or globally in the [configuration file](/documentation/ops-optimization/optimizer/). It prevents creating segments with a large amount of unindexed data for searches. Instead, once a segment reaches the so called `indexing_threshold`, all additional points will be added in 'deferred state'. Deferred points are not yet visible in reads but are still handled in writes. Deferred points will be promoted to visible points once the segment is optimized.
 
 In practice this behavior is good for three things. It prevents high search latencies because the search space on unoptimized data remains small. It prevents throttling update processing on large update queues. And it prevents creating a lot of small segments which would be expensive to optimize. A trade-off is eventual consistency, meaning updates might not be immediately visible. It can be mitigated by opting out on a per-update basis by setting `wait=true`. Or you might completely disable the feature by setting `indexed_only=false` and `prevent_unoptimized=false`.