diff --git a/docs/compatibility.md b/docs/compatibility.md
index 6d18ffc3..246d8631 100644
--- a/docs/compatibility.md
+++ b/docs/compatibility.md
@@ -1,16 +1,9 @@
 ---
 description: describes get by digest pitfall
-keywords:
-- registry, manifest, images, tags, repository, distribution, digest
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 9
-title: Compatibility
+keywords: registry, manifest, images, tags, repository, distribution, digest
+title: Registry compatibility
 ---
 
-# Registry Compatibility
-
 ## Synopsis
 *If a manifest is pulled by _digest_ from a registry 2.3 with Docker Engine 1.9
 and older, and the manifest was pushed with Docker Engine 1.10, a security check
@@ -81,4 +74,4 @@ constraints of CAS.*
 For this reason if a manifest is pulled by _digest_ from a registry 2.3 with Docker
 Engine 1.9 and older, and the manifest was pushed with Docker Engine 1.10, a
 security check will cause the Engine to receive a manifest it cannot use and the
-pull will fail.
+pull will fail.
\ No newline at end of file
diff --git a/docs/configuration.md b/docs/configuration.md
index 72c95972..d979cec7 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -1,16 +1,9 @@
 ---
 description: Explains how to configure a registry
-keywords:
-- registry, on-prem, images, tags, repository, distribution, configuration
-menu:
-  main:
-    parent: smn_registry
-    weight: 4
-title: Configuring a registry
+keywords: registry, on-prem, images, tags, repository, distribution, configuration
+title: Registry configuration reference
 ---
 
-# Registry Configuration Reference
-
 The Registry configuration is based on a YAML file, detailed below. While it comes with sane default values out of the box, you are heavily encouraged to review it exhaustively before moving your systems to production.
 
 ## Override specific configuration options
@@ -1863,4 +1856,4 @@ The following example illustrates these values:
 
 >**Note**: Cloudfront keys exist separately to other AWS keys.  See
 >[the documentation on AWS credentials](http://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)
->for more information.
+>for more information.
\ No newline at end of file
diff --git a/docs/deploying.md b/docs/deploying.md
index 1aa42aa0..7c674c00 100644
--- a/docs/deploying.md
+++ b/docs/deploying.md
@@ -1,16 +1,9 @@
 ---
 description: Explains how to deploy a registry
-keywords:
-- registry, on-prem, images, tags, repository, distribution, deployment
-menu:
-  main:
-    parent: smn_registry
-    weight: 3
+keywords: registry, on-prem, images, tags, repository, distribution, deployment
 title: Deploying a registry server
 ---
 
-# Deploying a registry server
-
 You need to [install Docker version 1.6.0 or newer](/engine/installation/index.md).
 
 ## Running on localhost
@@ -234,4 +227,4 @@ You will find more specific and advanced informations in the following sections:
  - [Advanced "recipes"](recipes/index.md)
  - [Registry API](spec/api.md)
  - [Storage driver model](storage-drivers/index.md)
- - [Token authentication](spec/auth/token.md)
+ - [Token authentication](spec/auth/token.md)
\ No newline at end of file
diff --git a/docs/deprecated.md b/docs/deprecated.md
index d30ff425..d3242b25 100644
--- a/docs/deprecated.md
+++ b/docs/deprecated.md
@@ -1,16 +1,9 @@
 ---
 description: describes deprecated functionality
-keywords:
-- registry, manifest, images, signatures, repository, distribution, digest
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 8
-title: Deprecated Features
+keywords: registry, manifest, images, signatures, repository, distribution, digest
+title: Docker Registry deprecation
 ---
 
-# Docker Registry Deprecation
-
 This document details functionality or components which are deprecated within
 the registry.
 
@@ -24,4 +17,4 @@ not stored in the registry.  This does not alter the functional behavior of
 the registry.
 
 Old signatures blobs can be removed from the registry storage by running the
-garbage-collect subcommand.
+garbage-collect subcommand.
\ No newline at end of file
diff --git a/docs/garbage-collection.md b/docs/garbage-collection.md
index d24bb77c..447a3d29 100644
--- a/docs/garbage-collection.md
+++ b/docs/garbage-collection.md
@@ -1,16 +1,9 @@
 ---
 description: High level discussion of garbage collection
-keywords:
-- registry, garbage, images, tags, repository, distribution
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 4
-title: Garbage Collection
+keywords: registry, garbage, images, tags, repository, distribution
+title: Garbage collection
 ---
 
-# Garbage Collection
-
 As of v2.4.0 a garbage collector command is included within the registry binary.
 This document describes what this command does and how and why it should be used.
 
@@ -133,5 +126,4 @@ blob eligible for deletion: sha256:7e15ce58ccb2181a8fced7709e9893206f0937cc9543b
 blob eligible for deletion: sha256:87192bdbe00f8f2a62527f36bb4c7c7f4eaf9307e4b87e8334fb6abec1765bcb
 blob eligible for deletion: sha256:b549a9959a664038fc35c155a95742cf12297672ca0ae35735ec027d55bf4e97
 blob eligible for deletion: sha256:f251d679a7c61455f06d793e43c06786d7766c88b8c24edf242b2c08e3c3f599
-```
-
+```
\ No newline at end of file
diff --git a/docs/help.md b/docs/help.md
index 8728924c..ea00fb53 100644
--- a/docs/help.md
+++ b/docs/help.md
@@ -1,16 +1,9 @@
 ---
 description: Getting help with the Registry
-keywords:
-- registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR
-menu:
-  main:
-    parent: smn_registry
-    weight: 9
-title: Getting help
+keywords: registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR
+title: Get help
 ---
 
-# Getting help
-
 If you need help, or just want to chat, you can reach us:
 
 - on irc: `#docker-distribution` on freenode
@@ -21,4 +14,4 @@ If you want to report a bug:
 - be sure to first read about [how to contribute](https://github.com/docker/distribution/blob/master/CONTRIBUTING.md)
 - you can then do so on the [GitHub project bugtracker](https://github.com/docker/distribution/issues)
 
-You can also find out more about the Docker's project [Getting Help resources](/opensource/get-help.md).
+You can also find out more about the Docker's project [Getting Help resources](/opensource/get-help.md).
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
index 0a57a2d3..b83ba55b 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,22 +1,16 @@
 ---
-aliases:
-- /registry/overview/
 description: High-level overview of the Registry
-keywords:
-- registry, on-prem, images, tags, repository, distribution
-menu:
-  main:
-    parent: smn_registry
-    weight: 1
-title: Registry Overview
+keywords: registry, on-prem, images, tags, repository, distribution
+redirect_from:
+- /registry/overview/
+title: Docker Registry
 ---
 
-# Docker Registry
-
 ## What it is
 
-The Registry is a stateless, highly scalable server side application that stores and lets you distribute Docker images.
-The Registry is open-source, under the permissive [Apache license](http://en.wikipedia.org/wiki/Apache_License).
+The Registry is a stateless, highly scalable server side application that stores
+and lets you distribute Docker images. The Registry is open-source, under the
+permissive [Apache license](http://en.wikipedia.org/wiki/Apache_License).
 
 ## Why use it
 
@@ -28,14 +22,19 @@ You should use the Registry if you want to:
 
 ## Alternatives
 
-Users looking for a zero maintenance, ready-to-go solution are encouraged to head-over to the [Docker Hub](https://hub.docker.com), which provides a free-to-use, hosted Registry, plus additional features (organization accounts, automated builds, and more).
+Users looking for a zero maintenance, ready-to-go solution are encouraged to
+head-over to the [Docker Hub](https://hub.docker.com), which provides a
+free-to-use, hosted Registry, plus additional features (organization accounts,
+automated builds, and more).
 
-Users looking for a commercially supported version of the Registry should look into [Docker Trusted Registry](/docker-trusted-registry/overview/).
+Users looking for a commercially supported version of the Registry should look
+into [Docker Trusted Registry](/docker-trusted-registry/overview/).
 
 ## Requirements
 
-The Registry is compatible with Docker engine **version 1.6.0 or higher**.
-If you really need to work with older Docker versions, you should look into the [old python registry](https://github.com/docker/docker-registry).
+The Registry is compatible with Docker engine **version 1.6.0 or higher**. If
+you really need to work with older Docker versions, you should look into the
+[old python registry](https://github.com/docker/docker-registry).
 
 ## TL;DR
 
@@ -65,4 +64,6 @@ Now stop your registry and remove all data
 
 ## Next
 
-You should now read the [detailed introduction about the registry](introduction.md), or jump directly to [deployment instructions](deploying.md).
+You should now read the [detailed introduction about the
+registry](introduction.md), or jump directly to [deployment
+instructions](deploying.md).
\ No newline at end of file
diff --git a/docs/insecure.md b/docs/insecure.md
index 0bb21458..f3c50d64 100644
--- a/docs/insecure.md
+++ b/docs/insecure.md
@@ -1,16 +1,9 @@
 ---
 description: Deploying a Registry in an insecure fashion
-keywords:
-- registry, on-prem, images, tags, repository, distribution, insecure
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 5
-title: Testing an insecure registry
+keywords: registry, on-prem, images, tags, repository, distribution, insecure
+title: Test an insecure registry
 ---
 
-# Insecure Registry
-
 While it's highly recommended to secure your registry using a TLS certificate
 issued by a known CA, you may alternatively decide to use self-signed
 certificates, or even use your registry over plain http.
@@ -111,4 +104,4 @@ update-ca-trust
 $ update-ca-trust enable
 ```
 
-Now restart docker (`service docker stop && service docker start`, or any other way you use to restart docker).
+Now restart docker (`service docker stop && service docker start`, or any other way you use to restart docker).
\ No newline at end of file
diff --git a/docs/introduction.md b/docs/introduction.md
index f95be819..8a15e2e7 100644
--- a/docs/introduction.md
+++ b/docs/introduction.md
@@ -1,17 +1,11 @@
 ---
 description: Explains what the Registry is, basic use cases and requirements
-keywords:
-- registry, on-prem, images, tags, repository, distribution, use cases, requirements
-menu:
-  main:
-    parent: smn_registry
-    weight: 2
-title: Understanding the Registry
+keywords: registry, on-prem, images, tags, repository, distribution, use cases, requirements
+title: About Registry
 ---
 
-# Understanding the Registry
-
-A registry is a storage and content delivery system, holding named Docker images, available in different tagged versions.
+A registry is a storage and content delivery system, holding named Docker
+images, available in different tagged versions.
 
   > Example: the image `distribution/registry`, with tags `2.0` and `2.1`.
 
@@ -19,13 +13,24 @@ Users interact with a registry by using docker push and pull commands.
 
   > Example: `docker pull registry-1.docker.io/distribution/registry:2.1`.
 
-Storage itself is delegated to drivers. The default storage driver is the local posix filesystem, which is suitable for development or small deployments. Additional cloud-based storage drivers like S3, Microsoft Azure, OpenStack Swift and Aliyun OSS are also supported. People looking into using other storage backends may do so by writing their own driver implementing the [Storage API](storage-drivers/index.md).
+Storage itself is delegated to drivers. The default storage driver is the local
+posix filesystem, which is suitable for development or small deployments.
+Additional cloud-based storage drivers like S3, Microsoft Azure, OpenStack Swift
+and Aliyun OSS are also supported. People looking into using other storage
+backends may do so by writing their own driver implementing the [Storage
+API](storage-drivers/index.md).
 
-Since securing access to your hosted images is paramount, the Registry natively supports TLS and basic authentication.
+Since securing access to your hosted images is paramount, the Registry natively
+supports TLS and basic authentication.
 
-The Registry GitHub repository includes additional information about advanced authentication and authorization methods. Only very large or public deployments are expected to extend the Registry in this way.
+The Registry GitHub repository includes additional information about advanced
+authentication and authorization methods. Only very large or public deployments
+are expected to extend the Registry in this way.
 
-Finally, the Registry ships with a robust [notification system](notifications.md), calling webhooks in response to activity, and both extensive logging and reporting, mostly useful for large installations that want to collect metrics.
+Finally, the Registry ships with a robust [notification
+system](notifications.md), calling webhooks in response to activity, and both
+extensive logging and reporting, mostly useful for large installations that want
+to collect metrics.
 
 ## Understanding image naming
 
@@ -34,22 +39,37 @@ Image names as used in typical docker commands reflect their origin:
  * `docker pull ubuntu` instructs docker to pull an image named `ubuntu` from the official Docker Hub. This is simply a shortcut for the longer `docker pull docker.io/library/ubuntu` command
  * `docker pull myregistrydomain:port/foo/bar` instructs docker to contact the registry located at `myregistrydomain:port` to find the image `foo/bar`
 
-You can find out more about the various Docker commands dealing with images in the [official Docker engine documentation](/engine/reference/commandline/cli.md).
+You can find out more about the various Docker commands dealing with images in
+the [official Docker engine
+documentation](/engine/reference/commandline/cli.md).
 
 ## Use cases
 
-Running your own Registry is a great solution to integrate with and complement your CI/CD system. In a typical workflow, a commit to your source revision control system would trigger a build on your CI system, which would then push a new image to your Registry if the build is successful. A notification from the Registry would then trigger a deployment on a staging environment, or notify other systems that a new image is available.
+Running your own Registry is a great solution to integrate with and complement
+your CI/CD system. In a typical workflow, a commit to your source revision
+control system would trigger a build on your CI system, which would then push a
+new image to your Registry if the build is successful. A notification from the
+Registry would then trigger a deployment on a staging environment, or notify
+other systems that a new image is available.
 
-It's also an essential component if you want to quickly deploy a new image over a large cluster of machines.
+It's also an essential component if you want to quickly deploy a new image over
+a large cluster of machines.
 
 Finally, it's the best way to distribute images inside an isolated network.
 
 ## Requirements
 
-You absolutely need to be familiar with Docker, specifically with regard to pushing and pulling images. You must understand the difference between the daemon and the cli, and at least grasp basic concepts about networking.
+You absolutely need to be familiar with Docker, specifically with regard to
+pushing and pulling images. You must understand the difference between the
+daemon and the cli, and at least grasp basic concepts about networking.
 
-Also, while just starting a registry is fairly easy, operating it in a production environment requires operational skills, just like any other service. You are expected to be familiar with systems availability and scalability, logging and log processing, systems monitoring, and security 101. Strong understanding of http and overall network communications, plus familiarity with golang are certainly useful as well for advanced operations or hacking.
+Also, while just starting a registry is fairly easy, operating it in a
+production environment requires operational skills, just like any other service.
+You are expected to be familiar with systems availability and scalability,
+logging and log processing, systems monitoring, and security 101. Strong
+understanding of http and overall network communications, plus familiarity with
+golang are certainly useful as well for advanced operations or hacking.
 
 ## Next
 
-Dive into [deploying your registry](deploying.md)
+Dive into [deploying your registry](deploying.md)
\ No newline at end of file
diff --git a/docs/notifications.md b/docs/notifications.md
index dd01a5b8..0646da0b 100644
--- a/docs/notifications.md
+++ b/docs/notifications.md
@@ -1,16 +1,9 @@
 ---
 description: Explains how to work with registry notifications
-keywords:
-- registry, on-prem, images, tags, repository, distribution, notifications, advanced
-menu:
-  main:
-    parent: smn_registry
-    weight: 5
-title: Working with notifications
+keywords: registry, on-prem, images, tags, repository, distribution, notifications, advanced
+title: Work with notifications
 ---
 
-# Notifications
-
 The Registry supports sending webhook notifications in response to events
 happening within the registry. Notifications are sent in response to manifest
 pushes and pulls and layer pushes and pulls. These actions are serialized into
@@ -347,4 +340,4 @@ provide acceptable guarantees, adding a transactional `Sink` to the registry
 is a possibility, although it may have an effect on request service time.
 Please see the
 [godoc](http://godoc.org/github.com/docker/distribution/notifications#Sink)
-for more information.
+for more information.
\ No newline at end of file
diff --git a/docs/recipes/apache.md b/docs/recipes/apache.md
index 1b503584..c60c64f9 100644
--- a/docs/recipes/apache.md
+++ b/docs/recipes/apache.md
@@ -1,16 +1,9 @@
 ---
 description: Restricting access to your registry using an apache proxy
-keywords:
-- registry, on-prem, images, tags, repository, distribution, authentication, proxy,
-  apache, httpd, TLS, recipe, advanced
-menu:
-  main:
-    parent: smn_recipes
-title: Authenticating proxy with apache
+keywords: registry, on-prem, images, tags, repository, distribution, authentication, proxy, apache, httpd, TLS, recipe, advanced
+title: Authenticate proxy with apache
 ---
 
-# Authenticating proxy with apache
-
 ## Use-case
 
 People already relying on an apache proxy to authenticate their users to other services might want to leverage it and have Registry communications tunneled through the same pipeline.
@@ -19,7 +12,7 @@ Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
 
 ### Alternatives
 
-If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](../deploying.md#native-basic-auth). 
+If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](../deploying.md#native-basic-auth).
 
 ### Solution
 
@@ -27,7 +20,7 @@ With the method presented here, you implement basic authentication for docker en
 
 While we use a simple htpasswd file as an example, any other apache authentication backend should be fairly easy to implement once you are done with the example.
 
-We also implement push restriction (to a limited user group) for the sake of the example. Again, you should modify this to fit your mileage. 
+We also implement push restriction (to a limited user group) for the sake of the example. Again, you should modify this to fit your mileage.
 
 ### Gotchas
 
@@ -200,7 +193,7 @@ Now, start your stack:
 
     docker-compose up -d
 
-Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image: 
+Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
 
     docker login myregistrydomain.com:5043
     docker tag ubuntu myregistrydomain.com:5043/test
@@ -213,4 +206,4 @@ Now, login with a "pull-only" user (using `testuser` and `testpassword`), then p
 
 Verify that the "pull-only" can NOT push:
 
-    docker push myregistrydomain.com:5043/test
+    docker push myregistrydomain.com:5043/test
\ No newline at end of file
diff --git a/docs/recipes/index.md b/docs/recipes/index.md
index 482a4894..12af3d29 100644
--- a/docs/recipes/index.md
+++ b/docs/recipes/index.md
@@ -1,16 +1,9 @@
 ---
 description: Fun stuff to do with your registry
-keywords:
-- registry, on-prem, images, tags, repository, distribution, recipes, advanced
-menu:
-  main:
-    parent: smn_recipes
-    weight: -10
+keywords: registry, on-prem, images, tags, repository, distribution, recipes, advanced
 title: Recipes Overview
 ---
 
-# Recipes
-
 You will find here a list of "recipes", end-to-end scenarios for exotic or otherwise advanced use-cases.
 
 Most users are not expected to have a use for these.
@@ -34,4 +27,4 @@ At this point, it's assumed that:
  * [using Apache as an authenticating proxy](apache.md)
  * [using Nginx as an authenticating proxy](nginx.md)
  * [running a Registry on macOS](osx-setup-guide.md)
- * [mirror the Docker Hub](mirror.md)
+ * [mirror the Docker Hub](mirror.md)
\ No newline at end of file
diff --git a/docs/recipes/mirror.md b/docs/recipes/mirror.md
index 6e66f73a..f6680449 100644
--- a/docs/recipes/mirror.md
+++ b/docs/recipes/mirror.md
@@ -1,59 +1,75 @@
 ---
 description: Setting-up a local mirror for Docker Hub images
-keywords:
-- registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe,
-  advanced
-menu:
-  main:
-    parent: smn_recipes
-title: Mirroring Docker Hub
+keywords: registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe, advanced
+title: Registry as a pull through cache
 ---
 
-# Registry as a pull through cache
-
 ## Use-case
 
-If you have multiple instances of Docker running in your environment (e.g., multiple physical or virtual machines, all running the Docker daemon), each time one of them requires an image that it doesn’t have it will go out to the internet and fetch it from the public Docker registry. By running a local registry mirror, you can keep most of the redundant image fetch traffic on your local network.
+If you have multiple instances of Docker running in your environment (e.g.,
+multiple physical or virtual machines, all running the Docker daemon), each time
+one of them requires an image that it doesn’t have it will go out to the
+internet and fetch it from the public Docker registry. By running a local
+registry mirror, you can keep most of the redundant image fetch traffic on your
+local network.
 
 ### Alternatives
 
-Alternatively, if the set of images you are using is well delimited, you can simply pull them manually and push them to a simple, local, private registry.
+Alternatively, if the set of images you are using is well delimited, you can
+simply pull them manually and push them to a simple, local, private registry.
 
-Furthermore, if your images are all built in-house, not using the Hub at all and relying entirely on your local registry is the simplest scenario.
+Furthermore, if your images are all built in-house, not using the Hub at all and
+relying entirely on your local registry is the simplest scenario.
 
 ### Gotcha
 
-It's currently not possible to mirror another private registry. Only the central Hub can be mirrored.
+It's currently not possible to mirror another private registry. Only the central
+Hub can be mirrored.
 
 ### Solution
 
-The Registry can be configured as a pull through cache.  In this mode a Registry responds to all normal docker pull requests but stores all content locally.
+The Registry can be configured as a pull through cache.  In this mode a Registry
+responds to all normal docker pull requests but stores all content locally.
 
 ## How does it work?
 
-The first time you request an image from your local registry mirror, it pulls the image from the public Docker registry and stores it locally before handing it back to you. On subsequent requests, the local registry mirror is able to serve the image from its own storage.
+The first time you request an image from your local registry mirror, it pulls
+the image from the public Docker registry and stores it locally before handing
+it back to you. On subsequent requests, the local registry mirror is able to
+serve the image from its own storage.
 
 ### What if the content changes on the Hub?
 
-When a pull is attempted with a tag, the Registry will check the remote to ensure if it has the latest version of the requested content.  If it doesn't it will fetch the latest content and cache it.
+When a pull is attempted with a tag, the Registry will check the remote to
+ensure if it has the latest version of the requested content.  If it doesn't it
+will fetch the latest content and cache it.
 
 ### What about my disk?
 
-In environments with high churn rates, stale data can build up in the cache.  When running as a pull through cache the Registry will periodically remove old content to save disk space. Subsequent requests for removed content will cause a remote fetch and local re-caching.
+In environments with high churn rates, stale data can build up in the cache.
+When running as a pull through cache the Registry will periodically remove old
+content to save disk space. Subsequent requests for removed content will cause a
+remote fetch and local re-caching.
 
-To ensure best performance and guarantee correctness the Registry cache should be configured to use the `filesystem` driver for storage.
+To ensure best performance and guarantee correctness the Registry cache should
+be configured to use the `filesystem` driver for storage.
 
 ## Running a Registry as a pull through cache
 
-The easiest way to run a registry as a pull through cache is to run the official Registry image.
+The easiest way to run a registry as a pull through cache is to run the official
+Registry image.
 
-Multiple registry caches can be deployed over the same back-end.  A single registry cache will ensure that concurrent requests do not pull duplicate data, but this property will not hold true for a registry cache cluster.
+Multiple registry caches can be deployed over the same back-end.  A single
+registry cache will ensure that concurrent requests do not pull duplicate data,
+but this property will not hold true for a registry cache cluster.
 
 ### Configuring the cache
 
-To configure a Registry to run as a pull through cache, the addition of a `proxy` section is required to the config file.
+To configure a Registry to run as a pull through cache, the addition of a
+`proxy` section is required to the config file.
 
-In order to access private images on the Docker Hub, a username and password can be supplied.
+In order to access private images on the Docker Hub, a username and password can
+be supplied.
 
     proxy:
       remoteurl: https://registry-1.docker.io
@@ -66,7 +82,8 @@ In order to access private images on the Docker Hub, a username and password can
 
 ### Configuring the Docker daemon
 
-You will need to pass the `--registry-mirror` option to your Docker daemon on startup:
+You will need to pass the `--registry-mirror` option to your Docker daemon on
+startup:
 
     docker --registry-mirror=https://<my-docker-mirror-host> daemon
 
@@ -74,4 +91,6 @@ For example, if your mirror is serving on `http://10.0.0.2:5000`, you would run:
 
     docker --registry-mirror=https://10.0.0.2:5000 daemon
 
-NOTE: Depending on your local host setup, you may be able to add the `--registry-mirror` option to the `DOCKER_OPTS` variable in `/etc/default/docker`.
+> NOTE: Depending on your local host setup, you may be able to add the
+`--registry-mirror` option to the `DOCKER_OPTS` variable in
+`/etc/default/docker`.
\ No newline at end of file
diff --git a/docs/recipes/nginx.md b/docs/recipes/nginx.md
index 94fca625..59f2fabf 100644
--- a/docs/recipes/nginx.md
+++ b/docs/recipes/nginx.md
@@ -1,42 +1,49 @@
 ---
 description: Restricting access to your registry using a nginx proxy
-keywords:
-- registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication,
-  TLS, recipe, advanced
-menu:
-  main:
-    parent: smn_recipes
-title: Authenticating proxy with nginx
+keywords: registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication, TLS, recipe, advanced
+title: Authenticate proxy with nginx
 ---
 
-# Authenticating proxy with nginx
-
-
 ## Use-case
 
-People already relying on a nginx proxy to authenticate their users to other services might want to leverage it and have Registry communications tunneled through the same pipeline.
+People already relying on a nginx proxy to authenticate their users to other
+services might want to leverage it and have Registry communications tunneled
+through the same pipeline.
 
-Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO mechanism fronting their internal http portal.
+Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
+mechanism fronting their internal http portal.
 
 ### Alternatives
 
-If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](../deploying.md#native-basic-auth).
+If you just want authentication for your registry, and are happy maintaining
+users access separately, you should really consider sticking with the native
+[basic auth registry feature](../deploying.md#native-basic-auth).
 
 ### Solution
 
-With the method presented here, you implement basic authentication for docker engines in a reverse proxy that sits in front of your registry.
+With the method presented here, you implement basic authentication for docker
+engines in a reverse proxy that sits in front of your registry.
 
-While we use a simple htpasswd file as an example, any other nginx authentication backend should be fairly easy to implement once you are done with the example.
+While we use a simple htpasswd file as an example, any other nginx
+authentication backend should be fairly easy to implement once you are done with
+the example.
 
-We also implement push restriction (to a limited user group) for the sake of the example. Again, you should modify this to fit your mileage.
+We also implement push restriction (to a limited user group) for the sake of the
+example. Again, you should modify this to fit your mileage.
 
 ### Gotchas
 
-While this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy, it also requires that you move TLS termination from the Registry to the proxy itself.
+While this model gives you the ability to use whatever authentication backend
+you want through the secondary authentication mechanism implemented inside your
+proxy, it also requires that you move TLS termination from the Registry to the
+proxy itself.
 
-Furthermore, introducing an extra http layer in your communication pipeline will make it more complex to deploy, maintain, and debug, and will possibly create issues. Make sure the extra complexity is required.
+Furthermore, introducing an extra http layer in your communication pipeline will
+make it more complex to deploy, maintain, and debug, and will possibly create
+issues. Make sure the extra complexity is required.
 
-For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets the following client header:
+For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets
+the following client header:
 
 ```
 X-Real-IP
@@ -44,7 +51,8 @@ X-Forwarded-For
 X-Forwarded-Proto
 ```
 
-So if you have an nginx sitting behind it, should remove these lines from the example config below:
+So if you have an nginx sitting behind it, should remove these lines from the
+example config below:
 
 ```
 X-Real-IP         $remote_addr; # pass on real client's IP
@@ -52,7 +60,9 @@ X-Forwarded-For   $proxy_add_x_forwarded_for;
 X-Forwarded-Proto $scheme;
 ```
 
-Otherwise nginx will reset the ELB's values, and the requests will not be routed properly. For more information, see [#970](https://github.com/docker/distribution/issues/970).
+Otherwise nginx will reset the ELB's values, and the requests will not be routed
+properly. For more information, see
+[#970](https://github.com/docker/distribution/issues/970).
 
 ## Setting things up
 
@@ -183,9 +193,10 @@ Now, start your stack:
 
     docker-compose up -d
 
-Login with a "push" authorized user (using `testuser` and `testpassword`), then tag and push your first image:
+Login with a "push" authorized user (using `testuser` and `testpassword`), then
+tag and push your first image:
 
     docker login -u=testuser -p=testpassword -e=root@example.ch myregistrydomain.com:5043
     docker tag ubuntu myregistrydomain.com:5043/test
     docker push myregistrydomain.com:5043/test
-    docker pull myregistrydomain.com:5043/test
+    docker pull myregistrydomain.com:5043/test
\ No newline at end of file
diff --git a/docs/recipes/osx-setup-guide.md b/docs/recipes/osx-setup-guide.md
index f926f8c9..73f9ad19 100644
--- a/docs/recipes/osx-setup-guide.md
+++ b/docs/recipes/osx-setup-guide.md
@@ -1,15 +1,9 @@
 ---
 description: Explains how to run a registry on macOS
-keywords:
-- registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced
-menu:
-  main:
-    parent: smn_recipes
-title: Running on macOS
+keywords: registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced
+title: macOS Setup Guide
 ---
 
-# macOS Setup Guide
-
 ## Use-case
 
 This is useful if you intend to run a registry server natively on macOS.
@@ -78,4 +72,4 @@ Start the Docker registry:
 
 ### Unloading the docker registry service
 
-    launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
+    launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
\ No newline at end of file
diff --git a/docs/spec/api.md b/docs/spec/api.md
index 45551b9e..d9b3d30c 100644
--- a/docs/spec/api.md
+++ b/docs/spec/api.md
@@ -1,15 +1,9 @@
 ---
 description: Specification for the Registry API.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced
-menu:
-  main:
-    parent: smn_registry_ref
-title: HTTP API V2
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
+title: Docker Registry HTTP API V2
 ---
 
-# Docker Registry HTTP API V2
-
 ## Introduction
 
 The _Docker Registry HTTP API_ is the protocol to facilitate distribution of
@@ -5481,4 +5475,4 @@ The following headers will be returned with the response:
 |Name|Description|
 |----|-----------|
 |`Content-Length`|Length of the JSON response body.|
-|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
+|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
\ No newline at end of file
diff --git a/docs/spec/auth/index.md b/docs/spec/auth/index.md
index 6b539f0e..469f3b3e 100644
--- a/docs/spec/auth/index.md
+++ b/docs/spec/auth/index.md
@@ -1,17 +1,10 @@
 ---
 description: Docker Registry v2 authentication schema
-keywords:
-- registry, on-prem, images, tags, repository, distribution, authentication, advanced
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 100
-title: Docker Registry Token Authentication
+keywords: registry, on-prem, images, tags, repository, distribution, authentication, advanced
+title: Docker Registry v2 authentication
 ---
 
-# Docker Registry v2 authentication
-
 See the [Token Authentication Specification](token.md),
 [Token Authentication Implementation](jwt.md),
 [Token Scope Documentation](scope.md),
-[OAuth2 Token Authentication](oauth.md) for more information.
+[OAuth2 Token Authentication](oauth.md) for more information.
\ No newline at end of file
diff --git a/docs/spec/auth/jwt.md b/docs/spec/auth/jwt.md
index e0a2e641..eaf05882 100644
--- a/docs/spec/auth/jwt.md
+++ b/docs/spec/auth/jwt.md
@@ -1,17 +1,9 @@
 ---
-description: Describe the reference implementation of the Docker Registry v2 authentication
-  schema
-keywords:
-- registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 101
-title: Token Authentication Implementation
+description: Describe the reference implementation of the Docker Registry v2 authentication schema
+keywords: registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
+title: Docker Registry v2 Bearer token specification
 ---
 
-# Docker Registry v2 Bearer token specification
-
 This specification covers the `docker/distribution` implementation of the
 v2 Registry's authentication schema.  Specifically, it describes the JSON
 Web Token schema that `docker/distribution` has adopted to implement the
@@ -332,4 +324,4 @@ authorization then the registry will return the appropriate error.
 
 At no point in this process should the registry need to call back to the
 authorization server. The registry only needs to be supplied with the trusted
-public keys to verify the token signatures.
+public keys to verify the token signatures.
\ No newline at end of file
diff --git a/docs/spec/auth/oauth.md b/docs/spec/auth/oauth.md
index ce0bcc49..02d9a138 100644
--- a/docs/spec/auth/oauth.md
+++ b/docs/spec/auth/oauth.md
@@ -1,16 +1,9 @@
 ---
 description: Specifies the Docker Registry v2 authentication
-keywords:
-- registry, on-prem, images, tags, repository, distribution, oauth2, advanced
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 102
-title: Oauth2 Token Authentication
+keywords: registry, on-prem, images, tags, repository, distribution, oauth2, advanced
+title: Docker Registry v2 authentication using OAuth2
 ---
 
-# Docker Registry v2 authentication using OAuth2
-
 This document describes support for the OAuth2 protocol within the authorization
 server. [RFC6749](https://tools.ietf.org/html/rfc6749) should be used as a
 reference for the protocol and HTTP endpoints described here.
@@ -187,5 +180,4 @@ HTTP/1.1 200 OK
 Content-Type: application/json
 
 {"refresh_token":"kas9Da81Dfa8","access_token":"eyJhbGciOiJFUzI1NiIsInR5":"expires_in":900,"scope":"repository:samalba/my-app:pull,repository:samalba/my-app:push"}
-```
-
+```
\ No newline at end of file
diff --git a/docs/spec/auth/scope.md b/docs/spec/auth/scope.md
index 8cd8699e..b0e1f3ce 100644
--- a/docs/spec/auth/scope.md
+++ b/docs/spec/auth/scope.md
@@ -1,17 +1,9 @@
 ---
-description: Describes the scope and access fields used for registry authorization
-  tokens
-keywords:
-- registry, on-prem, images, tags, repository, distribution, advanced, access, scope
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 103
-title: Token Scope Documentation
+description: Describes the scope and access fields used for registry authorization tokens
+keywords: registry, on-prem, images, tags, repository, distribution, advanced, access, scope
+title: Docker Registry token scope and access
 ---
 
-# Docker Registry Token Scope and Access
-
 Tokens used by the registry are always restricted what resources they may
 be used to access, where those resources may be accessed, and what actions
 may be done on those resources. Tokens always have the context of a user which
@@ -140,5 +132,4 @@ restricting scope to specific type, name, and actions combinations should be
 done by fetching an access token using the refresh token. Since the refresh
 token is not scoped to specific resources for an audience, extra care should
 be taken to only use the refresh token to negotiate new access tokens directly
-with the authorization server, and never with a resource provider.
-
+with the authorization server, and never with a resource provider.
\ No newline at end of file
diff --git a/docs/spec/auth/token.md b/docs/spec/auth/token.md
index fa49357e..a33867f3 100644
--- a/docs/spec/auth/token.md
+++ b/docs/spec/auth/token.md
@@ -1,17 +1,9 @@
 ---
 description: Specifies the Docker Registry v2 authentication
-keywords:
-- registry, on-prem, images, tags, repository, distribution, Bearer authentication,
-  advanced
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: 104
-title: Token Authentication Specification
+keywords: registry, on-prem, images, tags, repository, distribution, Bearer authentication, advanced
+title: Docker Registry v2 authentication via central service
 ---
 
-# Docker Registry v2 authentication via central service
-
 This document outlines the v2 Docker registry authentication scheme:
 
 ![v2 registry auth](../../images/v2-registry-auth.png)
@@ -26,7 +18,7 @@ This document outlines the v2 Docker registry authentication scheme:
 5. The client retries the original request with the Bearer token embedded in
    the request's Authorization header.
 6. The Registry authorizes the client by validating the Bearer token and the
-   claim set embedded within it and begins the push/pull session as usual. 
+   claim set embedded within it and begins the push/pull session as usual.
 
 ## Requirements
 
@@ -82,7 +74,8 @@ Note the HTTP Response Header indicating the auth challenge:
 Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:samalba/my-app:pull,push"
 ```
 
-This format is documented in [Section 3 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-3)
+This format is documented in [Section 3 of RFC 6750: The OAuth 2.0 Authorization
+Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-3)
 
 This challenge indicates that the registry requires a token issued by the
 specified token server and that the request the client is attempting will
@@ -162,7 +155,7 @@ Defines getting a bearer and refresh token using the token endpoint.
         <code>expires_in</code>
     </dt>
     <dd>
-        (Optional) The duration in seconds since the token was issued that it 
+        (Optional) The duration in seconds since the token was issued that it
         will remain valid.  When omitted, this defaults to 60 seconds.  For
         compatibility with older clients, a token should never be returned with
         less than 60 seconds to live.
@@ -253,4 +246,5 @@ token placed in the HTTP `Authorization` header like so:
 Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkJWM0Q6MkFWWjpVQjVaOktJQVA6SU5QTDo1RU42Ok40SjQ6Nk1XTzpEUktFOkJWUUs6M0ZKTDpQT1RMIn0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJCQ0NZOk9VNlo6UUVKNTpXTjJDOjJBVkM6WTdZRDpBM0xZOjQ1VVc6NE9HRDpLQUxMOkNOSjU6NUlVTCIsImF1ZCI6InJlZ2lzdHJ5LmRvY2tlci5jb20iLCJleHAiOjE0MTUzODczMTUsIm5iZiI6MTQxNTM4NzAxNSwiaWF0IjoxNDE1Mzg3MDE1LCJqdGkiOiJ0WUpDTzFjNmNueXk3a0FuMGM3cktQZ2JWMUgxYkZ3cyIsInNjb3BlIjoiamxoYXduOnJlcG9zaXRvcnk6c2FtYWxiYS9teS1hcHA6cHVzaCxwdWxsIGpsaGF3bjpuYW1lc3BhY2U6c2FtYWxiYTpwdWxsIn0.Y3zZSwaZPqy4y9oRBVRImZyv3m_S9XDHF1tWwN7mL52C_IiA73SJkWVNsvNqpJIn5h7A2F8biv_S2ppQ1lgkbw
 ```
 
-This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)
+This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization
+Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)
\ No newline at end of file
diff --git a/docs/spec/index.md b/docs/spec/index.md
index 7ad0aaea..23d47252 100644
--- a/docs/spec/index.md
+++ b/docs/spec/index.md
@@ -1,17 +1,10 @@
 ---
 description: Explains registry JSON objects
-keywords:
-- registry, service, images, repository,  json
-menu:
-  main:
-    parent: smn_registry_ref
-    weight: -1
-title: Reference Overview
+keywords: registry, service, images, repository,  json
+title: Docker Registry Reference
 ---
 
-# Docker Registry Reference
-
 * [HTTP API V2](api.md)
 * [Storage Driver](../storage-drivers/index.md)
 * [Token Authentication Specification](auth/token.md)
-* [Token Authentication Implementation](auth/jwt.md)
+* [Token Authentication Implementation](auth/jwt.md)
\ No newline at end of file
diff --git a/docs/spec/json.md b/docs/spec/json.md
index e5d0d304..46703903 100644
--- a/docs/spec/json.md
+++ b/docs/spec/json.md
@@ -1,16 +1,10 @@
 ---
 description: Explains registry JSON objects
+keywords: registry, service, images, repository,  json
 published: false
-keywords:
-- registry, service, images, repository,  json
-menu:
-  main:
-    parent: smn_registry_ref
-title: Docker Distribution JSON Canonicalization
+title: Docker Distribution JSON canonicalization
 ---
 
-# Docker Distribution JSON Canonicalization
-
 To provide consistent content hashing of JSON objects throughout Docker
 Distribution APIs, the specification defines a canonical JSON format. Adopting
 such a canonicalization also aids in caching JSON responses.
@@ -89,4 +83,4 @@ var canonical bytes.Buffer
 if err := json.Indent(&canonical, incoming, "", ""); err != nil {
 	// ... handle error
 }
-```
+```
\ No newline at end of file
diff --git a/docs/spec/manifest-v2-1.md b/docs/spec/manifest-v2-1.md
index 3162f3f8..bcdf86c5 100644
--- a/docs/spec/manifest-v2-1.md
+++ b/docs/spec/manifest-v2-1.md
@@ -1,15 +1,9 @@
 ---
 description: image manifest for the Registry.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
-menu:
-  main:
-    parent: smn_registry_ref
-title: 'Image Manifest V 2, Schema 1 '
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
+title: Image manifest V2, schema 1
 ---
 
-# Image Manifest Version 2, Schema 1
-
 This document outlines the format of of the V2 image manifest. The image
 manifest described herein was introduced in the Docker daemon in the [v1.3.0
 release](https://github.com/docker/docker/commit/9f482a66ab37ec396ac61ed0c00d59122ac07453).
@@ -164,4 +158,4 @@ by *libtrust*.  A signature consists of the following fields:
    ]
 }
 
-```
+```
\ No newline at end of file
diff --git a/docs/spec/manifest-v2-2.md b/docs/spec/manifest-v2-2.md
index eaf9295c..628fac0d 100644
--- a/docs/spec/manifest-v2-2.md
+++ b/docs/spec/manifest-v2-2.md
@@ -1,15 +1,9 @@
 ---
 description: image manifest for the Registry.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
-menu:
-  main:
-    parent: smn_registry_ref
-title: 'Image Manifest V 2, Schema 2 '
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
+title: Image manifest V2, schema 2
 ---
 
-# Image Manifest Version 2, Schema 2
-
 This document outlines the format of of the V2 image manifest, schema version 2.
 The original (and provisional) image manifest for V2 (schema 1), was introduced
 in the Docker daemon in the [v1.3.0
@@ -295,4 +289,4 @@ their own, but only serve to fill in the parent chain in a compatible way.
 The IDs in these synthetic configurations will be derived from hashes of their
 respective blobs. The registry will create these configurations and their IDs
 using the same scheme as Docker 1.10 when it creates a legacy manifest to push
-to a registry which doesn't support the new format.
+to a registry which doesn't support the new format.
\ No newline at end of file
diff --git a/docs/storage-drivers/azure.md b/docs/storage-drivers/azure.md
index 64e476e4..ed87fb4c 100644
--- a/docs/storage-drivers/azure.md
+++ b/docs/storage-drivers/azure.md
@@ -1,15 +1,9 @@
 ---
 description: Explains how to use the Azure storage drivers
-keywords:
-- registry, service, driver, images, storage,  azure
-menu:
-  main:
-    parent: smn_storagedrivers
+keywords: registry, service, driver, images, storage,  azure
 title: Microsoft Azure storage driver
 ---
 
-# Microsoft Azure storage driver
-
 An implementation of the `storagedriver.StorageDriver` interface which uses [Microsoft Azure Blob Storage](http://azure.microsoft.com/en-us/services/storage/) for object storage.
 
 ## Parameters
@@ -74,4 +68,4 @@ An implementation of the `storagedriver.StorageDriver` interface which uses [Mic
 * To get information about
 [azure-blob-storage](http://azure.microsoft.com/en-us/services/storage/) visit
 the Microsoft website.
-* You can use Microsoft's [Blob Service REST API](https://msdn.microsoft.com/en-us/library/azure/dd135733.aspx) to [create a container] (https://msdn.microsoft.com/en-us/library/azure/dd179468.aspx).
+* You can use Microsoft's [Blob Service REST API](https://msdn.microsoft.com/en-us/library/azure/dd135733.aspx) to [create a container] (https://msdn.microsoft.com/en-us/library/azure/dd179468.aspx).
\ No newline at end of file
diff --git a/docs/storage-drivers/filesystem.md b/docs/storage-drivers/filesystem.md
index 2c7f6628..39361622 100644
--- a/docs/storage-drivers/filesystem.md
+++ b/docs/storage-drivers/filesystem.md
@@ -1,15 +1,9 @@
 ---
 description: Explains how to use the filesystem storage drivers
-keywords:
-- registry, service, driver, images, storage,  filesystem
-menu:
-  main:
-    parent: smn_storagedrivers
+keywords: registry, service, driver, images, storage,  filesystem
 title: Filesystem storage driver
 ---
 
-# Filesystem storage driver
-
 An implementation of the `storagedriver.StorageDriver` interface which uses the local filesystem.
 
 ## Parameters
@@ -20,4 +14,4 @@ there is adequate space available. Defaults to `/var/lib/registry`.
 `maxthreads`: (optional) The maximum number of simultaneous blocking filesystem
 operations permitted within the registry. Each operation spawns a new thread and
 may cause thread exhaustion issues if many are done in parallel. Defaults to
-`100`, and can be no lower than `25`.
+`100`, and can be no lower than `25`.
\ No newline at end of file
diff --git a/docs/storage-drivers/gcs.md b/docs/storage-drivers/gcs.md
index 4c8a7c88..d256f354 100644
--- a/docs/storage-drivers/gcs.md
+++ b/docs/storage-drivers/gcs.md
@@ -1,15 +1,9 @@
 ---
 description: Explains how to use the Google Cloud Storage drivers
-keywords:
-- registry, service, driver, images, storage,  gcs, google, cloud
-menu:
-  main:
-    parent: smn_storagedrivers
-title: GCS storage driver
+keywords: registry, service, driver, images, storage,  gcs, google, cloud
+title: Google Cloud Storage driver
 ---
 
-# Google Cloud Storage driver
-
 An implementation of the `storagedriver.StorageDriver` interface which uses Google Cloud for object storage.
 
 ## Parameters
@@ -74,4 +68,4 @@ An implementation of the `storagedriver.StorageDriver` interface which uses Goog
 
 **Note** Instead of a key file you can use [Google Application Default Credentials](https://developers.google.com/identity/protocols/application-default-credentials).
 
-`rootdirectory`: (optional) The root directory tree in which all registry files will be stored. Defaults to the empty string (bucket root).
+`rootdirectory`: (optional) The root directory tree in which all registry files will be stored. Defaults to the empty string (bucket root).
\ No newline at end of file
diff --git a/docs/storage-drivers/index.md b/docs/storage-drivers/index.md
index 1c9fbe9d..b0b88e4b 100644
--- a/docs/storage-drivers/index.md
+++ b/docs/storage-drivers/index.md
@@ -1,19 +1,11 @@
 ---
-aliases:
-- /registry/storagedrivers/
 description: Explains how to use storage drivers
-keywords:
-- registry, on-prem, images, tags, repository, distribution, storage drivers, advanced
-menu:
-  main:
-    identifier: storage_index
-    parent: smn_storagedrivers
-    weight: -1
-title: Storage Driver overview
+keywords: registry, on-prem, images, tags, repository, distribution, storage drivers, advanced
+redirect_from:
+- /registry/storagedrivers/
+title: Docker Registry storage driver
 ---
 
-# Docker Registry Storage Driver
-
 This document describes the registry storage driver model, implementation, and explains how to contribute new storage drivers.
 
 ## Provided Drivers
@@ -63,4 +55,4 @@ Storage drivers should call `factory.Register` with their driver name in an `ini
 Storage driver test suites are provided in
 `storagedriver/testsuites/testsuites.go` and may be used for any storage
 driver written in Go. Tests can be registered using the `RegisterSuite`
-function, which run the same set of tests for any registered drivers.
+function, which run the same set of tests for any registered drivers.
\ No newline at end of file
diff --git a/docs/storage-drivers/inmemory.md b/docs/storage-drivers/inmemory.md
index 6fbed6aa..cc92b5c2 100644
--- a/docs/storage-drivers/inmemory.md
+++ b/docs/storage-drivers/inmemory.md
@@ -1,15 +1,9 @@
 ---
 description: Explains how to use the in-memory storage drivers
-keywords:
-- registry, service, driver, images, storage,  in-memory
-menu:
-  main:
-    parent: smn_storagedrivers
-title: In-memory storage driver
+keywords: registry, service, driver, images, storage,  in-memory
+title: In-memory storage driver (testing only)
 ---
 
-# In-memory storage driver (Testing Only)
-
 For purely tests purposes, you can use the `inmemory` storage driver. This
 driver is an implementation of the `storagedriver.StorageDriver` interface which
 uses local memory for object storage. If you would like to run a registry from
@@ -19,4 +13,4 @@ volatile memory, use the [`filesystem` driver](filesystem.md) on a ramdisk.
 
 ## Parameters
 
-None
+None
\ No newline at end of file
diff --git a/docs/storage-drivers/oss.md b/docs/storage-drivers/oss.md
index 44109003..2e49c803 100644
--- a/docs/storage-drivers/oss.md
+++ b/docs/storage-drivers/oss.md
@@ -1,16 +1,11 @@
 ---
 description: Explains how to use the Aliyun OSS storage driver
-keywords:
-- registry, service, driver, images, storage, OSS, aliyun
-menu:
-  main:
-    parent: smn_storagedrivers
+keywords: registry, service, driver, images, storage, OSS, aliyun
 title: Aliyun OSS storage driver
 ---
 
-# Aliyun OSS storage driver
-
-An implementation of the `storagedriver.StorageDriver` interface which uses [Aliyun OSS](http://www.aliyun.com/product/oss) for object storage.
+An implementation of the `storagedriver.StorageDriver` interface which uses
+[Aliyun OSS](http://www.aliyun.com/product/oss) for object storage.
 
 ## Parameters
 
@@ -123,4 +118,4 @@ no
 <td> The root directory tree in which to store all registry files. Defaults to an empty string (bucket root).
 </td>
 </tr>
-</table>
+</table>
\ No newline at end of file
diff --git a/docs/storage-drivers/s3.md b/docs/storage-drivers/s3.md
index cf729490..7f27f475 100644
--- a/docs/storage-drivers/s3.md
+++ b/docs/storage-drivers/s3.md
@@ -1,16 +1,11 @@
 ---
 description: Explains how to use the S3 storage drivers
-keywords:
-- registry, service, driver, images, storage,  S3
-menu:
-  main:
-    parent: smn_storagedrivers
+keywords: registry, service, driver, images, storage,  S3
 title: S3 storage driver
 ---
 
-# S3 storage driver
-
-An implementation of the `storagedriver.StorageDriver` interface which uses Amazon S3 or S3 compatible services for object storage.
+An implementation of the `storagedriver.StorageDriver` interface which uses
+Amazon S3 or S3 compatible services for object storage.
 
 ## Parameters
 
@@ -221,17 +216,25 @@ The following IAM permissions are required by the registry for push and pull.  S
 
 ## Use Case
 
-Adding CloudFront as a middleware for your S3 backed registry can dramatically improve pull times. Your registry will have the ability to retrieve your images from edge servers, rather than the geographically limited location of your S3 bucket. The farther your registry is from your bucket, the more improvements you will see. See [Amazon CloudFront](https://aws.amazon.com/cloudfront/details/).
+Adding CloudFront as a middleware for your S3 backed registry can dramatically
+improve pull times. Your registry will have the ability to retrieve your images
+from edge servers, rather than the geographically limited location of your S3
+bucket. The farther your registry is from your bucket, the more improvements you
+will see. See [Amazon CloudFront](https://aws.amazon.com/cloudfront/details/).
 
 ## Configuring CloudFront for Distribution
 
-If you are unfamiliar with creating a CloudFront distribution, see [Getting Started with Cloudfront](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
+If you are unfamiliar with creating a CloudFront distribution, see [Getting
+Started with
+Cloudfront](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
 
 Defaults can be kept in most areas except:
 
 ### Origin:
 
-The CloudFront distribution must be created such that the `Origin Path` is set to the directory level of the root "docker" key in S3. If your registry exists on the root of the bucket, this path should be left blank.
+The CloudFront distribution must be created such that the `Origin Path` is set
+to the directory level of the root "docker" key in S3. If your registry exists
+on the root of the bucket, this path should be left blank.
 
 ### Behaviors:
 
@@ -243,7 +246,9 @@ The CloudFront distribution must be created such that the `Origin Path` is set t
 
 ## Registry configuration
 
-Here the `middleware` option is used. It is still important to keep the `storage` option as CloudFront will only handle `pull` actions; `push` actions are still directly written to S3.
+Here the `middleware` option is used. It is still important to keep the
+`storage` option as CloudFront will only handle `pull` actions; `push` actions
+are still directly written to S3.
 
 The following example shows what you will need at minimum:
 
@@ -265,4 +270,6 @@ middleware:
 
 ## CloudFront Key-Pair
 
-A CloudFront key-pair is required for all AWS accounts needing access to your CloudFront distribution. For information, please see [Creating CloudFront Key Pairs](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).
+A CloudFront key-pair is required for all AWS accounts needing access to your
+CloudFront distribution. For information, please see [Creating CloudFront Key
+Pairs](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).
\ No newline at end of file
diff --git a/docs/storage-drivers/swift.md b/docs/storage-drivers/swift.md
index eaa80511..44a3f4f7 100644
--- a/docs/storage-drivers/swift.md
+++ b/docs/storage-drivers/swift.md
@@ -1,16 +1,12 @@
 ---
 description: Explains how to use the OpenStack swift storage driver
-keywords:
-- registry, service, driver, images, storage,  swift
-menu:
-  main:
-    parent: smn_storagedrivers
-title: Swift storage driver
+keywords: registry, service, driver, images, storage,  swift
+title: OpenStack Swift storage driver
 ---
 
-# OpenStack Swift storage driver
-
-An implementation of the `storagedriver.StorageDriver` interface that uses [OpenStack Swift](http://docs.openstack.org/developer/swift/) for object storage.
+An implementation of the `storagedriver.StorageDriver` interface that uses
+[OpenStack Swift](http://docs.openstack.org/developer/swift/) for object
+storage.
 
 ## Parameters
 
@@ -210,8 +206,9 @@ An implementation of the `storagedriver.StorageDriver` interface that uses [Open
   </tr>
 </table>
 
-The features supported by the Swift server are queried by requesting the `/info` URL on the server. In case the administrator
-disabled that feature, the configuration file can specify the following optional parameters :
+The features supported by the Swift server are queried by requesting the `/info`
+URL on the server. In case the administrator disabled that feature, the
+configuration file can specify the following optional parameters :
 
 <table>
 <tr>
@@ -242,4 +239,4 @@ disabled that feature, the configuration file can specify the following optional
     </p>
     </td>
 </tr>
-</table>
+</table>
\ No newline at end of file