diff --git a/site/config/api/pkg.tpl b/site/config/api/pkg.tpl
index 7ca2d3ed56..c5250235f7 100644
--- a/site/config/api/pkg.tpl
+++ b/site/config/api/pkg.tpl
@@ -1,11 +1,14 @@
 {{ define "packages" }}
 ---
-title: "API Reference"
-description: "NGINX Gateway API Reference"
+title: "API reference"
 weight: 100
 toc: false
 ---
 
+## Overview
+
+NGINX Gateway API Reference
+
 {{ with .packages}}
 <p>Packages:</p>
 <ul>
diff --git a/site/content/how-to/_index.md b/site/content/how-to/_index.md
index 969045d4d8..4239eabfe5 100644
--- a/site/content/how-to/_index.md
+++ b/site/content/how-to/_index.md
@@ -1,9 +1,4 @@
 ---
-title: "How-To Guides"
-description:
+title: "How-to guides"
 weight: 300
-linkTitle: "Guides"
-menu:
-  docs:
-    parent: NGINX Gateway Fabric
 ---
diff --git a/site/content/how-to/configuration/_index.md b/site/content/how-to/configuration/_index.md
deleted file mode 100644
index cd5e67c0e8..0000000000
--- a/site/content/how-to/configuration/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Configuration"
-description:
-weight: 200
-linkTitle: "Configuration"
-menu:
-  docs:
-    parent: How-To Guides
----
diff --git a/site/content/how-to/configuration/control-plane-configuration.md b/site/content/how-to/control-plane-configuration.md
similarity index 94%
rename from site/content/how-to/configuration/control-plane-configuration.md
rename to site/content/how-to/control-plane-configuration.md
index 03f9376469..293679185a 100644
--- a/site/content/how-to/configuration/control-plane-configuration.md
+++ b/site/content/how-to/control-plane-configuration.md
@@ -1,11 +1,12 @@
 ---
-title: "Control Plane Configuration"
-description: "Learn how to dynamically update the Gateway Fabric control plane configuration."
-weight: 100
+title: "Control plane configuration"
+weight: 300
 toc: true
 docs: "DOCS-1416"
 ---
 
+Learn how to dynamically update the Gateway Fabric control plane configuration.
+
 ## Overview
 
 NGINX Gateway Fabric can dynamically update the control plane configuration without restarting. The control plane configuration is stored in the NginxGateway custom resource, created during the installation of NGINX Gateway Fabric.
diff --git a/site/content/how-to/maintenance/_index.md b/site/content/how-to/maintenance/_index.md
deleted file mode 100644
index dd64b81b48..0000000000
--- a/site/content/how-to/maintenance/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Maintenance and Upgrades"
-description:
-weight: 500
-linkTitle: "Maintenance and Upgrades"
-menu:
-  docs:
-    parent: How-To Guides
----
diff --git a/site/content/how-to/monitoring/_index.md b/site/content/how-to/monitoring/_index.md
index c649a3153b..4f947a883a 100644
--- a/site/content/how-to/monitoring/_index.md
+++ b/site/content/how-to/monitoring/_index.md
@@ -1,9 +1,4 @@
 ---
-title: "Monitoring and Troubleshooting"
-description:
-weight: 400
-linkTitle: "Monitoring and Troubleshooting"
-menu:
-  docs:
-    parent: How-To Guides
+title: "Monitoring and troubleshooting"
+weight: 200
 ---
diff --git a/site/content/how-to/monitoring/dashboard.md b/site/content/how-to/monitoring/dashboard.md
index 8ff5dc79c4..835363d65e 100644
--- a/site/content/how-to/monitoring/dashboard.md
+++ b/site/content/how-to/monitoring/dashboard.md
@@ -1,12 +1,11 @@
 ---
-title: "NGINX Plus Dashboard"
-description: "Learn how to view the NGINX Plus dashboard to see real-time metrics."
+title: "NGINX Plus dashboard"
 weight: 300
 toc: true
 docs: "DOCS-1417"
 ---
 
-{{<custom-styles>}}
+Learn how to view the NGINX Plus dashboard to see real-time metrics.
 
 ## Overview
 
diff --git a/site/content/how-to/monitoring/prometheus.md b/site/content/how-to/monitoring/prometheus.md
index d0238051e2..d95b2bba64 100644
--- a/site/content/how-to/monitoring/prometheus.md
+++ b/site/content/how-to/monitoring/prometheus.md
@@ -1,16 +1,14 @@
 ---
-title: "Prometheus Metrics"
-description: "This document describes how to monitor NGINX Gateway Fabric using Prometheus and Grafana. It explains installation and configuration, as well as what metrics are available."
+title: "Prometheus metrics"
 weight: 100
 toc: true
 docs: "DOCS-1418"
 ---
 
-{{<custom-styles>}}
+This document describes how to monitor NGINX Gateway Fabric using Prometheus and Grafana. It explains installation and configuration, as well as what metrics are available.
 
 ## Overview
 
-
 NGINX Gateway Fabric metrics are displayed in [Prometheus](https://prometheus.io/) format. These metrics are served through a metrics server orchestrated by the controller-runtime package on HTTP port `9113`. When installed, Prometheus automatically scrapes this port and collects metrics. [Grafana](https://grafana.com/) can be used for rich visualization of these metrics.
 
 {{<call-out "important" "Security note for metrics">}}
@@ -98,7 +96,7 @@ Provided by the [controller-runtime](https://github.com/kubernetes-sigs/controll
 - Go runtime metrics such as the number of Go routines, garbage collection duration, and Go version.
 - Controller-specific metrics, including reconciliation errors per controller, length of the reconcile queue, and reconciliation latency.
 
-## How to change the default metrics configuration
+## Change the default metrics configuration
 
 You can configure monitoring metrics for NGINX Gateway Fabric using Helm or Manifests.
 
diff --git a/site/content/how-to/monitoring/tracing.md b/site/content/how-to/monitoring/tracing.md
index bc39f48406..72bc90bbf9 100644
--- a/site/content/how-to/monitoring/tracing.md
+++ b/site/content/how-to/monitoring/tracing.md
@@ -17,7 +17,7 @@ This guide explains how to enable tracing on HTTPRoutes using NGINX Gateway Fabr
 Tracing cannot be enabled for [HTTPRoute matches](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch) with `headers`, `params`, or `method` matchers defined. It will be added in a future release.
 {{< /important >}}
 
-## Install the Collectors
+## Install the collectors
 
 The first step is to install the collectors. NGINX Gateway Fabric will be configured to export to the OpenTelemetry Collector, which is configured to export to Jaeger. This model allows the visualization collector (Jaeger) to be swapped with something else, or to add more collectors without needing to reconfigure NGINX Gateway Fabric. It is also possible to configure NGINX Gateway Fabric to export directly to Jaeger.
 
@@ -333,7 +333,7 @@ Select a trace to view the attributes.
 
 The trace includes the attribute from the global NginxProxy resource as well as the attribute from the ObservabilityPolicy.
 
-## Further Reading
+## Further reading
 
 - [Custom policies]({{< relref "overview/custom-policies.md" >}}): learn about how NGINX Gateway Fabric custom policies work.
 - [API reference]({{< relref "reference/api.md" >}}): all configuration fields for the policies mentioned in this guide
diff --git a/site/content/how-to/monitoring/troubleshooting.md b/site/content/how-to/monitoring/troubleshooting.md
index e15bee6a1c..efb2457011 100644
--- a/site/content/how-to/monitoring/troubleshooting.md
+++ b/site/content/how-to/monitoring/troubleshooting.md
@@ -5,11 +5,8 @@ toc: true
 docs: "DOCS-1419"
 ---
 
-{{< custom-styles >}}
-
 This topic describes possible issues when using NGINX Gateway Fabric and general troubleshooting techniques. When possible, suggested workarounds are provided.
 
-
 ### General troubleshooting
 
 When investigating a problem or requesting help, there are important data points that can be collected to help understand what issues may exist.
diff --git a/site/content/how-to/traffic-management/_index.md b/site/content/how-to/traffic-management/_index.md
index 8bf8679eac..eb4895183f 100644
--- a/site/content/how-to/traffic-management/_index.md
+++ b/site/content/how-to/traffic-management/_index.md
@@ -1,9 +1,4 @@
 ---
-title: "Traffic Management"
-description:
-weight: 300
-linkTitle: "Traffic Management"
-menu:
-  docs:
-    parent: How-To Guides
+title: "Traffic management"
+weight: 100
 ---
diff --git a/site/content/how-to/traffic-management/advanced-routing.md b/site/content/how-to/traffic-management/advanced-routing.md
index 0e318614cf..4ccf1e0bac 100644
--- a/site/content/how-to/traffic-management/advanced-routing.md
+++ b/site/content/how-to/traffic-management/advanced-routing.md
@@ -1,20 +1,23 @@
 ---
-title: "Routing to Applications Using HTTP Matching Conditions"
-description: "Learn how to deploy multiple applications and HTTPRoutes with request conditions such as paths, methods, headers, and query parameters"
+title: "Application routes using HTTP matching conditions"
 weight: 200
 toc: true
 docs: "DOCS-1422"
 ---
 
+Learn how to deploy multiple applications and HTTPRoutes with request conditions such as paths, methods, headers, and query parameters
+
+## Overview
+
 In this guide we will configure advanced routing rules for multiple applications. These rules will showcase request matching by path, headers, query parameters, and method. For an introduction to exposing your application, we recommend that you follow the [basic guide]({{< relref "/how-to/traffic-management/routing-traffic-to-your-app.md" >}}) first.
 
 The following image shows the traffic flow that we will be creating with these rules.
 
-{{<img src="img/advanced-routing.png" alt="Traffic Flow Diagram">}}
+{{<img src="img/advanced-routing.png" alt="">}}
 
 The goal is to create a set of rules that will result in client requests being sent to specific backends based on the request attributes. In this diagram, we have two versions of the `coffee` service. Traffic for v1 needs to be directed to the old application, while traffic for v2 needs to be directed towards the new application. We also have two `tea` services, one that handles GET operations and one that handles POST operations. Both the `tea` and `coffee` applications share the same Gateway.
 
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "/installation/" >}}) NGINX Gateway Fabric.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP
@@ -27,9 +30,9 @@ The goal is to create a set of rules that will result in client requests being s
 
 {{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}}
 
-## Coffee Applications
+## Coffee applications
 
-### Deploy the Coffee Applications
+### Deploy the Coffee applications
 
 Begin by deploying the `coffee-v1` and `coffee-v2` applications:
 
@@ -37,7 +40,7 @@ Begin by deploying the `coffee-v1` and `coffee-v2` applications:
 kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-gateway-fabric/v1.3.0/examples/advanced-routing/coffee.yaml
 ```
 
-### Deploy the Gateway API Resources for the Coffee Applications
+### Deploy the Gateway API Resources for the Coffee applications
 
 The [gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) resource is typically deployed by the [cluster operator](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#roles-and-personas_1). To deploy the gateway:
 
@@ -111,7 +114,7 @@ This HTTPRoute has a few important properties:
 
   If you want both conditions to be required, you can define headers and queryParams in the same match object.
 
-### Send Traffic to Coffee
+### Send traffic to Coffee
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee applications.
 
@@ -147,17 +150,17 @@ Server address: 10.244.0.9:8080
 Server name: coffee-v2-68bd55f798-s9z5q
 ```
 
-## Tea Applications
+## Tea applications
 
 Let's deploy a different set of applications now called `tea` and `tea-post`. These applications will have their own set of rules, but will still attach to the same gateway listener as the `coffee` apps.
 
-### Deploy the Tea Applications
+### Deploy the Tea applications
 
 ```shell
 kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-gateway-fabric/v1.3.0/examples/advanced-routing/tea.yaml
 ```
 
-### Deploy the HTTPRoute for the Tea Services
+### Deploy the HTTPRoute for the Tea services
 
 We are reusing the previous gateway for these applications, so all we need to create is the HTTPRoute.
 
@@ -199,7 +202,7 @@ The properties of this HTTPRoute include:
 - The first rule defines that a POST request to the `/tea` path is routed to the `tea-post` Service.
 - The second rule defines that a GET request to the `/tea` path is routed to the `tea` Service.
 
-### Send Traffic to Tea
+### Send traffic to Tea
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our tea applications.
 
@@ -332,7 +335,7 @@ If you have any issues while sending traffic, try the following to debug your co
 
   Check for any error messages in the conditions.
 
-## Further Reading
+## Further reading
 
 To learn more about the Gateway API and the resources we created in this guide, check out the following Kubernetes documentation resources:
 
diff --git a/site/content/how-to/traffic-management/client-settings.md b/site/content/how-to/traffic-management/client-settings.md
index 0ce78942f0..43aaeefd1e 100644
--- a/site/content/how-to/traffic-management/client-settings.md
+++ b/site/content/how-to/traffic-management/client-settings.md
@@ -1,5 +1,5 @@
 ---
-title: "Client Settings Policy"
+title: "Client Settings Policy API"
 weight: 800
 toc: true
 docs: "DOCS-000"
@@ -148,7 +148,6 @@ Events:                      <none>
 
 Next, test that the policy is configured by sending a POST request to the coffee and tea applications exceeding the client's max body size of 50 bytes.
 
-
 ```shell
 curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee -X POST --data "this payload is greater than fifty bytes by four bytes"
 ```
@@ -279,7 +278,7 @@ spec:
 EOF
 ```
 
-## Further Reading
+## Further reading
 
 - [Custom policies]({{< relref "overview/custom-policies.md" >}}): learn about how NGINX Gateway Fabric custom policies work.
 - [API reference]({{< relref "reference/api.md" >}}): all configuration fields for the `ClientSettingsPolicy` API.
diff --git a/site/content/how-to/traffic-management/https-termination.md b/site/content/how-to/traffic-management/https-termination.md
index 67f5df7543..971de72ba6 100644
--- a/site/content/how-to/traffic-management/https-termination.md
+++ b/site/content/how-to/traffic-management/https-termination.md
@@ -1,14 +1,17 @@
 ---
-title: "HTTPS Termination"
-description: "Learn how to terminate HTTPS traffic using NGINX Gateway Fabric."
-weight: 500
+title: "HTTPS termination"
+weight: 600
 toc: true
 docs: "DOCS-1421"
 ---
 
+Learn how to terminate HTTPS traffic using NGINX Gateway Fabric.
+
+## Overview
+
 In this guide, we will show how to configure HTTPS termination for your application, using an [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) redirect filter, secret, and [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/).
 
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP address and port of NGINX Gateway Fabric into shell variables:
@@ -85,7 +88,7 @@ NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
 service/coffee       ClusterIP   10.96.189.37   <none>        80/TCP    40s
 ```
 
-## Configure HTTPS Termination and Routing
+## Configure HTTPS termination and routing
 
 For the HTTPS, we need a certificate and key that are stored in a secret. This secret will live in a separate namespace, so we will need a ReferenceGrant in order to access it.
 
@@ -238,7 +241,7 @@ Server address: 10.244.0.6:80
 Server name: coffee-6b8b6d6486-7fc78
 ```
 
-## Further Reading
+## Further reading
 
 To learn more about redirects using the Gateway API, see the following resource:
 
diff --git a/site/content/how-to/traffic-management/integrating-cert-manager.md b/site/content/how-to/traffic-management/integrating-cert-manager.md
index bbcba4f4df..09f0f8f169 100644
--- a/site/content/how-to/traffic-management/integrating-cert-manager.md
+++ b/site/content/how-to/traffic-management/integrating-cert-manager.md
@@ -1,11 +1,14 @@
 ---
-title: "Securing Traffic using Let's Encrypt and Cert-Manager"
-description: "Learn how to issue and mange certificates using Let's Encrypt and cert-manager."
+title: "Secure traffic using Let's Encrypt and cert-manager"
 weight: 300
 toc: true
 docs: "DOCS-1425"
 ---
 
+Learn how to issue and mange certificates using Let's Encrypt and cert-manager.
+
+## Overview
+
 Securing client server communication is a crucial part of modern application architectures. One of the most important steps in this process is implementing HTTPS (HTTP over TLS/SSL) for all communications. This encrypts the data transmitted between the client and server, preventing eavesdropping and tampering. To do this, you need an SSL/TLS certificate from a trusted Certificate Authority (CA). However, issuing and managing certificates can be a complicated manual process. Luckily, there are many services and tools available to simplify and automate certificate issuance and management.
 
 Follow the steps in this guide to:
@@ -14,14 +17,14 @@ Follow the steps in this guide to:
 - Use [Let’s Encrypt](https://letsencrypt.org) as the Certificate Authority (CA) issuing the TLS certificate.
 - Use [cert-manager](https://cert-manager.io) to automate the provisioning and management of the certificate.
 
-## Prerequisities
+## Before you begin
 
 - Administrator access to a Kubernetes cluster.
 - [Helm](https://helm.sh) and [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) must be installed locally.
 - [NGINX Gateway Fabric deployed]({{< relref "/installation/" >}}) in the Kubernetes cluster.
 - A DNS-resolvable domain name is required. It must resolve to the public endpoint of the NGINX Gateway Fabric deployment, and this public endpoint must be an external IP address or alias accessible over the internet. The process here will depend on your DNS provider. This DNS name will need to be resolvable from the Let’s Encrypt servers, which may require that you wait for the record to propagate before it will work.
 
-## Overview
+## Secure traffic using Let's Encrypt and cert-manage
 
 {{<img src="img/cert-manager-gateway-workflow.png" alt="cert-manager ACME challenge and certificate management with Gateway API">}}
 
@@ -37,7 +40,7 @@ At a high level, the process looks like this:
 1. When the client connects to `https://cafe.example.com/coffee`, the request is routed to the coffee-app application and the communication is secured using the signed keypair contained in the cafe-secret secret.
 1. The certificate will be automatically renewed when it is close to expiry, the secret will be updated using the new certificate, and NGINX Gateway Fabric will dynamically update the keypair on the filesystem used by NGINX for HTTPS termination once the secret is updated.
 
-## Securing Traffic
+## Securing traffic
 
 ### Deploy cert-manager
 
diff --git a/site/content/how-to/traffic-management/redirects-and-rewrites.md b/site/content/how-to/traffic-management/redirects-and-rewrites.md
index 218dba7af4..184650f32a 100644
--- a/site/content/how-to/traffic-management/redirects-and-rewrites.md
+++ b/site/content/how-to/traffic-management/redirects-and-rewrites.md
@@ -1,11 +1,14 @@
 ---
-title: "HTTP Redirects and Rewrites"
-description: "Learn how to redirect or rewrite your HTTP traffic using NGINX Gateway Fabric."
+title: "HTTP redirects and rewrites"
 weight: 400
 toc: true
 docs: "DOCS-1424"
 ---
 
+Learn how to redirect or rewrite your HTTP traffic using NGINX Gateway Fabric.
+
+## Overview
+
 [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) filters can be used to configure HTTP redirects or rewrites. Redirects return HTTP 3XX responses to a client, instructing it to retrieve a different resource. Rewrites modify components of a client request (such as hostname and/or path) before proxying it upstream.
 
 {{< note >}}NGINX Gateway Fabric currently does not support path-based redirects.{{< /note >}}
@@ -14,7 +17,7 @@ To see an example of a redirect using scheme and port, see the [HTTPS Terminatio
 
 In this guide, we will be configuring a path URL rewrite.
 
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP address and port of NGINX Gateway Fabric into shell variables:
@@ -84,7 +87,7 @@ NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
 service/coffee       ClusterIP   10.96.189.37   <none>        80/TCP    40s
 ```
 
-## Configure a Path Rewrite
+## Configure a path rewrite
 
 To create the **cafe** gateway, copy and paste the following into your terminal:
 
@@ -153,7 +156,7 @@ spec:
 EOF
 ```
 
-## Send Traffic
+## Send traffic
 
 Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee application.
 
@@ -196,7 +199,7 @@ Server name: coffee-6b8b6d6486-7fc78
 URI: /prices
 ```
 
-## Further Reading
+## Further reading
 
 To learn more about redirects and rewrites using the Gateway API, see the following resource:
 
diff --git a/site/content/how-to/traffic-management/response-headers.md b/site/content/how-to/traffic-management/response-headers.md
index 03d6f60da0..62076861ed 100644
--- a/site/content/how-to/traffic-management/response-headers.md
+++ b/site/content/how-to/traffic-management/response-headers.md
@@ -1,18 +1,20 @@
 ---
-title: "HTTP Response Headers"
-description: "Learn how to modify the response headers of your application using NGINX Gateway Fabric."
-weight: 700
+title: "HTTP response headers"
+weight: 500
 toc: true
 ---
 
+Learn how to modify the response headers of your application using NGINX Gateway Fabric.
+
+## Overview
+
 [HTTP Header Modifiers](https://gateway-api.sigs.k8s.io/guides/http-header-modifier/?h=request#http-header-modifiers) can be used to add, modify or remove headers during the request-response lifecycle. The [ResponseHeaderModifier](https://gateway-api.sigs.k8s.io/guides/http-header-modifier/#http-response-header-modifier) is used to alter headers in a response to the client.
 
 In this guide we will modify the headers for HTTP responses when client requests are made. For an introduction to exposing your application, we recommend that you follow the [basic guide]({{< relref "/how-to/traffic-management/routing-traffic-to-your-app.md" >}}) first.
 
 We'll begin by configuring an app with custom headers and a straightforward HTTPRoute. We'll then observe the server response in relation to header responses. Next, we'll delve into modifying some of those headers using an HTTPRoute with filters to modify *response* headers. Our aim will be to verify whether the server responds with the modified headers.
 
-
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "/installation/" >}}) NGINX Gateway Fabric.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP
@@ -99,7 +101,7 @@ This HTTPRoute has a few important properties:
 - `cafe.example.com` is the hostname that is matched for all requests to the backends defined in this HTTPRoute.
 - The `match` rule defines that all requests with the path prefix `/headers` are sent to the `headers` Service.
 
-### Send Traffic to the Headers Application
+### Send traffic to the Headers application
 
 We will use `curl` with the `-i` flag to access the application and include the response headers in the output:
 
@@ -131,7 +133,7 @@ In the output above, you can see that the headers application adds the following
 
 In the next section we will modify these headers by adding a ResponseHeaderModifier filter to the headers HTTPRoute.
 
-### Update the HTTPRoute to Modify the Response Headers
+### Update the HTTPRoute to modify the Response headers
 
 Let's update the HTTPRoute by adding a `ResponseHeaderModifier` filter:
 
@@ -176,7 +178,7 @@ Notice that this HTTPRoute has a `ResponseHeaderModifier` filter defined for the
 - Removes `X-Header-Remove` header.
 
 
-### Send Traffic to the Modified Headers Application
+### Send traffic to the modified Headers application
 
 We will send a curl request to the modified `headers` application and verify the response headers are modified.
 
diff --git a/site/content/how-to/traffic-management/routing-traffic-to-your-app.md b/site/content/how-to/traffic-management/routing-traffic-to-your-app.md
index cf310df780..2a19111bd6 100644
--- a/site/content/how-to/traffic-management/routing-traffic-to-your-app.md
+++ b/site/content/how-to/traffic-management/routing-traffic-to-your-app.md
@@ -1,16 +1,17 @@
 ---
-title: "Routing Traffic to Your Application"
-description: "Learn how to route external traffic to your Kubernetes applications using NGINX Gateway Fabric."
+title: "Routing traffic to applications"
 weight: 100
 toc: true
 docs: "DOCS-1426"
 ---
 
-{{<custom-styles>}}
+Learn how to route external traffic to your Kubernetes applications using NGINX Gateway Fabric.
+
+## Overview
 
 You can route traffic to your Kubernetes applications using the Gateway API and NGINX Gateway Fabric. Whether you're managing a web application or a REST backend API, you can use NGINX Gateway Fabric to expose your application outside the cluster.
 
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP address and port of NGINX Gateway Fabric into shell variables:
@@ -24,7 +25,7 @@ You can route traffic to your Kubernetes applications using the Gateway API and
 
 The application we are going to use in this guide is a simple **coffee** application comprised of one service and two pods:
 
-{{<img src="img/route-all-traffic-app.png" alt="coffee app">}}
+{{<img src="img/route-all-traffic-app.png" alt="">}}
 
 Using this architecture, the **coffee** application is not accessible outside the cluster. We want to expose this application on the hostname "cafe.example.com" so that clients outside the cluster can access it.
 
@@ -169,7 +170,7 @@ The [**rules**](https://gateway-api.sigs.k8s.io/references/spec/#gateway.network
 
 ## Test the configuration
 
-To test the configuration, we will send a request to the public IP and port of NGINX Gateway Fabric that you saved in the [prerequisites](#prerequisites) section and verify that the response comes from one of the **coffee** pods.
+To test the configuration, we will send a request to the public IP and port of NGINX Gateway Fabric that you saved in the [Before you begin](#before-you-begin) section and verify that the response comes from one of the **coffee** pods.
 
 {{< note >}}Your clients should be able to resolve the domain name "cafe.example.com" to the public IP of the NGINX Gateway Fabric. In this guide we will simulate that using curl's `--resolve` option. {{< /note >}}
 
@@ -360,7 +361,7 @@ If you have any issues while testing the configuration, try the following to deb
 
 If your issue persists, [contact us](https://github.com/nginxinc/nginx-gateway-fabric#contacts).
 
-## Further Reading
+## Further reading
 
 To learn more about the Gateway API and the resources we created in this guide, check out the following resources:
 
diff --git a/site/content/how-to/traffic-management/securing-backend-traffic.md b/site/content/how-to/traffic-management/securing-backend-traffic.md
index edb0b1eaa3..cdbf618acb 100644
--- a/site/content/how-to/traffic-management/securing-backend-traffic.md
+++ b/site/content/how-to/traffic-management/securing-backend-traffic.md
@@ -1,14 +1,18 @@
 ---
-title: "Securing Traffic to Backends"
-description: "Learn how to encrypt HTTP traffic between NGINX Gateway Fabric and your backend pods."
-weight: 600
+title: "Securing backend traffic"
+description:
+weight: 700
 toc: true
 docs: "DOCS-1423"
 ---
 
+Learn how to encrypt HTTP traffic between NGINX Gateway Fabric and your backend pods.
+
+## Overview
+
 In this guide, we will show how to specify the TLS configuration of the connection from the Gateway to a backend pod/s via the Service API object using a [BackendTLSPolicy](https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/). This covers the use-case where the service or backend owner is doing their own TLS and NGINX Gateway Fabric needs to know how to connect to this backend pod that has its own certificate over HTTPS.
 
-## Prerequisites
+## Before you begin
 
 - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric. Please note that the Gateway APIs from the experimental channel are required, and NGF must be deployed with the `--gateway-api-experimental-features` flag.
 - [Expose NGINX Gateway Fabric]({{< relref "installation/expose-nginx-gateway-fabric.md" >}}) and save the public IP address and port of NGINX Gateway Fabric into shell variables:
@@ -122,7 +126,7 @@ NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
 service/secure-app   ClusterIP   10.96.213.57   <none>        8443/TCP  9s
 ```
 
-## Configure Routing rules
+## Configure routing rules
 
 First, we will create the Gateway resource with an HTTP listener:
 
@@ -189,7 +193,7 @@ curl --resolve secure-app.example.com:$GW_PORT:$GW_IP http://secure-app.example.
 
 We can see we a status 400 Bad Request message from NGINX.
 
-## Create the Backend TLS configuration
+## Create the backend TLS configuration
 
 To configure the backend TLS terminationm, first we will create the ConfigMap that holds the `ca.crt` entry for verifying our self-signed certificates:
 
@@ -305,7 +309,7 @@ curl --resolve secure-app.example.com:$GW_PORT:$GW_IP http://secure-app.example.
 hello from pod secure-app
 ```
 
-## Further Reading
+## Further reading
 
 To learn more about configuring backend TLS termination using the Gateway API, see the following resources:
 
diff --git a/site/content/how-to/maintenance/upgrade-apps-without-downtime.md b/site/content/how-to/upgrade-apps-without-downtime.md
similarity index 98%
rename from site/content/how-to/maintenance/upgrade-apps-without-downtime.md
rename to site/content/how-to/upgrade-apps-without-downtime.md
index 01763efe7d..a7cc07b67d 100644
--- a/site/content/how-to/maintenance/upgrade-apps-without-downtime.md
+++ b/site/content/how-to/upgrade-apps-without-downtime.md
@@ -1,12 +1,11 @@
 ---
 title: "Upgrade applications without downtime"
-description: "Learn how to use NGINX Gateway Fabric to upgrade applications without downtime."
-weight: 100
+weight: 400
 toc: true
 docs: "DOCS-1420"
 ---
 
-{{<custom-styles>}}
+Learn how to use NGINX Gateway Fabric to upgrade applications without downtime.
 
 ## Overview
 
diff --git a/site/content/includes/installation/jwt-password-note.md b/site/content/includes/installation/jwt-password-note.md
index 2f12808252..4cfeec8b92 100644
--- a/site/content/includes/installation/jwt-password-note.md
+++ b/site/content/includes/installation/jwt-password-note.md
@@ -1,5 +1,5 @@
 ---
-docs:
+docs: "DOCS-000"
 ---
 
 {{< note >}} For security, follow these practices with JSON Web Tokens (JWTs), passwords, and shell history:
diff --git a/site/content/installation/expose-nginx-gateway-fabric.md b/site/content/installation/expose-nginx-gateway-fabric.md
index 36671525be..2acbf349cd 100644
--- a/site/content/installation/expose-nginx-gateway-fabric.md
+++ b/site/content/installation/expose-nginx-gateway-fabric.md
@@ -1,13 +1,10 @@
 ---
 title: "Expose NGINX Gateway Fabric"
-description: ""
 weight: 300
 toc: true
 docs: "DOCS-1427"
 ---
 
-{{<custom-styles>}}
-
 ## Overview
 
 Gain access to NGINX Gateway Fabric by creating either a **NodePort** service or a **LoadBalancer** service in the same namespace as the controller. The service name is specified in the `--service` argument of the controller.
diff --git a/site/content/installation/installing-ngf/_index.md b/site/content/installation/installing-ngf/_index.md
index 7a23488b82..401f982246 100644
--- a/site/content/installation/installing-ngf/_index.md
+++ b/site/content/installation/installing-ngf/_index.md
@@ -1,8 +1,8 @@
 ---
-title: "Installing NGINX Gateway Fabric"
+title: "Install NGINX Gateway Fabric"
 description:
 weight: 100
-linkTitle: "Installing NGINX Gateway Fabric"
+linkTitle: "Install NGINX Gateway Fabric"
 menu:
   docs:
     parent: Installation
diff --git a/site/content/installation/installing-ngf/helm.md b/site/content/installation/installing-ngf/helm.md
index bf22bb6b39..4a70620763 100644
--- a/site/content/installation/installing-ngf/helm.md
+++ b/site/content/installation/installing-ngf/helm.md
@@ -1,14 +1,15 @@
 ---
 title: "Installation with Helm"
-description: "Learn how to install, upgrade, and uninstall NGINX Gateway Fabric in a Kubernetes cluster with Helm."
 weight: 100
 toc: true
 docs: "DOCS-1430"
 ---
 
-{{<custom-styles>}}
+## Overview
 
-## Prerequisites
+Learn how to install, upgrade, and uninstall NGINX Gateway Fabric in a Kubernetes cluster using Helm.
+
+## Before you begin
 
 To complete this guide, you'll need to install:
 
diff --git a/site/content/installation/installing-ngf/manifests.md b/site/content/installation/installing-ngf/manifests.md
index 2c41d1907a..3e5b37e9c2 100644
--- a/site/content/installation/installing-ngf/manifests.md
+++ b/site/content/installation/installing-ngf/manifests.md
@@ -1,14 +1,15 @@
 ---
 title: "Installation with Kubernetes manifests"
-description: "Learn how to install, upgrade, and uninstall NGINX Gateway Fabric using Kubernetes manifests."
 weight: 200
 toc: true
 docs: "DOCS-1429"
 ---
 
-{{<custom-styles>}}
+## Overview
 
-## Prerequisites
+Learn how to install, upgrade, and uninstall NGINX Gateway Fabric using Kubernetes manifests.
+
+## Before you begin
 
 To complete this guide, you'll need to install:
 
diff --git a/site/content/installation/ngf-images/building-the-images.md b/site/content/installation/ngf-images/building-the-images.md
index 92391caede..f80b72271b 100644
--- a/site/content/installation/ngf-images/building-the-images.md
+++ b/site/content/installation/ngf-images/building-the-images.md
@@ -1,12 +1,10 @@
 ---
-title: "Building NGINX Gateway Fabric and NGINX Images"
+title: "Build NGINX Gateway Fabric and NGINX images"
 weight: 300
 toc: true
 docs: "DOCS-1431"
 ---
 
-{{<custom-styles>}}
-
 ## Overview
 
 While most users will install NGINX Gateway Fabric [with Helm]({{< relref "/installation/installing-ngf/helm.md" >}}) or [Kubernetes manifests]({{< relref "/installation/installing-ngf/manifests.md" >}}), manually building the [NGINX Gateway Fabric and NGINX images]({{< relref "/overview/gateway-architecture.md#the-nginx-gateway-fabric-pod" >}}) can be helpful for testing and development purposes. Follow the steps in this document to build the NGINX Gateway Fabric and NGINX images.
diff --git a/site/content/installation/ngf-images/jwt-token-docker-secret.md b/site/content/installation/ngf-images/jwt-token-docker-secret.md
index c32d708023..3fddec3cc2 100644
--- a/site/content/installation/ngf-images/jwt-token-docker-secret.md
+++ b/site/content/installation/ngf-images/jwt-token-docker-secret.md
@@ -1,6 +1,5 @@
 ---
-title: "Getting the NGINX Plus image using JWT"
-description: "This document describes how to use a JWT token to get an NGINX Plus image for NGINX Gateway Fabric from the F5 Docker registry."
+title: "Get the NGINX Plus image using JWT"
 weight: 100
 doctypes: ["install"]
 toc: true
@@ -9,6 +8,8 @@ docs: "DOCS-1432"
 
 ## Overview
 
+This document describes how to use a JWT token to get an NGINX Plus image for NGINX Gateway Fabric from the F5 Docker registry.
+
 Follow the steps in this document to pull the NGINX Plus image for NGINX Gateway Fabric from the F5 Docker registry into your Kubernetes cluster using your JWT token. To list available image tags using the Docker registry API, you will also need to download its certificate and key from [MyF5](https://my.f5.com).
 
 {{<important>}}An NGINX Plus subscription will not work with these instructions. For NGINX Gateway Fabric, you must have an Connectivity Stack for Kubernetes subscription.{{</important>}}
diff --git a/site/content/installation/ngf-images/pulling-ngf-image.md b/site/content/installation/ngf-images/pulling-ngf-image.md
index 741b6c7644..c7afc1233b 100644
--- a/site/content/installation/ngf-images/pulling-ngf-image.md
+++ b/site/content/installation/ngf-images/pulling-ngf-image.md
@@ -1,14 +1,14 @@
 ---
-title: "Pushing an NGINX Plus image to a private registry"
-description: "This document describes how to pull a NGINX Plus image for NGINX Gateway Fabric from the official F5 Docker registry and upload it to your private registry."
+title: "Push an NGINX Plus image to a private registry"
 weight: 200
 doctypes: ["install"]
 toc: true
 docs: "DOCS-1433"
 ---
 
-{{<custom-styles>}}
+## Overview
 
+This document describes how to pull a NGINX Plus image for NGINX Gateway Fabric from the official F5 Docker registry and upload it to your private registry
 
 ## Before you begin
 
@@ -17,7 +17,6 @@ Before you start, you'll need these installed on your machine:
 - [Docker v18.09 or higher](https://docs.docker.com/engine/release-notes/18.09/).
 - The certificate (**nginx-repo.crt**) and key (**nginx-repo.key**) for a Connectivity Stack for Kubernetes subscription, obtainable from [MyF5l](https://my.f5.com) An NGINX Plus certificate and key will not work.
 
-
 ## Configuring Docker for the F5 Container Registry
 
 To configure Docker to communicate with the F5 Container Registry, first create a folder containing your certificate and key files:
diff --git a/site/content/installation/running-on-kind.md b/site/content/installation/running-on-kind.md
index 69edefc5ec..b63df6aa02 100644
--- a/site/content/installation/running-on-kind.md
+++ b/site/content/installation/running-on-kind.md
@@ -1,14 +1,15 @@
 ---
-title: "Deploying NGINX Gateway Fabric on a kind Cluster"
-description: "Learn how to run NGINX Gateway Fabric on a kind (Kubernetes in Docker) cluster."
+title: "Deploy NGINX Gateway Fabric on a kind Cluster"
 weight: 400
 toc: true
 docs: "DOCS-1428"
 ---
 
-{{< custom-styles >}}
+## Overview
 
-## Prerequisites
+Learn how to run NGINX Gateway Fabric on a kind (Kubernetes in Docker) cluster.
+
+## Before you begin
 
 To complete the steps in this guide, you first need to install the following tools for Kubernetes management and development:
 
@@ -102,6 +103,6 @@ kubectl -n nginx-gateway port-forward <pod-name> 8080:80 8443:443
 
 {{< note >}}NGINX will only start listening on these ports after you set up a [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/#gateway) resource with a valid listener.{{</note>}}
 
-## Getting Started with NGINX Gateway Fabric
+## Get Started with NGINX Gateway Fabric
 
 Learn how to use NGINX Gateway Fabric by exploring the tutorials in the [examples](https://github.com/nginxinc/nginx-gateway-fabric/tree/v1.3.0/examples) directory. The guides provide practical instructions and scenarios to help you use NGINX Gateway Fabric effectively.
diff --git a/site/content/installation/usage-reporting.md b/site/content/installation/usage-reporting.md
index a3f1e5c96e..d23e296834 100644
--- a/site/content/installation/usage-reporting.md
+++ b/site/content/installation/usage-reporting.md
@@ -1,6 +1,5 @@
 ---
-title: "Enabling Usage Reporting for NGINX Plus"
-description: "This page outlines how to enable Usage Reporting for NGINX Gateway Fabric and how to view the usage data through the API."
+title: "Enable Usage Reporting for NGINX Plus"
 weight: 1000
 toc: true
 docs: "DOCS-000"
@@ -8,6 +7,8 @@ docs: "DOCS-000"
 
 ## Overview
 
+This document describes how to enable Usage Reporting for NGINX Gateway Fabric and how to view the usage data through the API.
+
 Usage Reporting connects to the NGINX Instance Manager and reports the number of Nodes and NGINX Gateway Fabric Pods in the cluster.
 
 To use Usage Reporting, you must have access to [NGINX Instance Manager](https://www.nginx.com/products/nginx-management-suite/instance-manager). Usage Reporting is a requirement of the new Flexible Consumption Program for NGINX Gateway Fabric, used to calculate costs. **This only applies if using NGINX Plus as the data plane.** Usage is reported every 24 hours.
diff --git a/site/content/overview/gateway-api-compatibility.md b/site/content/overview/gateway-api-compatibility.md
index 567b3c5af0..c2094de2ae 100644
--- a/site/content/overview/gateway-api-compatibility.md
+++ b/site/content/overview/gateway-api-compatibility.md
@@ -1,11 +1,12 @@
 ---
 title: "Gateway API Compatibility"
-description: "Learn which Gateway API resources NGINX Gateway Fabric supports and the extent of that support."
 weight: 200
 toc: true
 docs: "DOCS-1412"
 ---
 
+Learn which Gateway API resources NGINX Gateway Fabric supports and to which level.
+
 ## Summary
 
 {{< bootstrap-table "table table-striped table-bordered" >}}
diff --git a/site/content/overview/gateway-architecture.md b/site/content/overview/gateway-architecture.md
index d87cd7f930..d2a197920b 100644
--- a/site/content/overview/gateway-architecture.md
+++ b/site/content/overview/gateway-architecture.md
@@ -1,19 +1,21 @@
 ---
-title: "Gateway Architecture"
-description: "Learn about the architecture and design principles of NGINX Gateway Fabric."
+title: "Gateway architecture"
 weight: 100
 toc: true
 docs: "DOCS-1413"
 ---
 
+Learn about the architecture and design principles of NGINX Gateway Fabric.
+
 The intended audience for this information is primarily the two following groups:
 
+
 - _Cluster Operators_ who would like to know how the software works and understand how it can fail.
 - _Developers_ who would like to [contribute](https://github.com/nginxinc/nginx-gateway-fabric/blob/main/CONTRIBUTING.md) to the project.
 
 The reader needs to be familiar with core Kubernetes concepts, such as pods, deployments, services, and endpoints. For an understanding of how NGINX itself works, you can read the ["Inside NGINX: How We Designed for Performance & Scale"](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/) blog post.
 
-## NGINX Gateway Fabric Overview
+## Overview
 
 NGINX Gateway Fabric is an open source project that provides an implementation of the [Gateway API](https://gateway-api.sigs.k8s.io/) using [NGINX](https://nginx.org/) as the data plane. The goal of this project is to implement the core Gateway APIs -- _Gateway_, _GatewayClass_, _HTTPRoute_, _GRPCRoute_, _TCPRoute_, _TLSRoute_, and _UDPRoute_ -- to configure an HTTP or TCP/UDP load balancer, reverse proxy, or API gateway for applications running on Kubernetes. NGINX Gateway Fabric supports a subset of the Gateway API.
 
diff --git a/site/content/overview/nginx-plus.md b/site/content/overview/nginx-plus.md
index e2fd39e238..e79a97d1de 100644
--- a/site/content/overview/nginx-plus.md
+++ b/site/content/overview/nginx-plus.md
@@ -1,5 +1,5 @@
 ---
-title: "Advanced features of NGINX Plus"
+title: "Advanced features with NGINX Plus"
 weight: 300
 toc: true
 docs: "DOCS-1415"
diff --git a/site/content/overview/product-telemetry.md b/site/content/overview/product-telemetry.md
index f69b641718..4b222c5b6b 100644
--- a/site/content/overview/product-telemetry.md
+++ b/site/content/overview/product-telemetry.md
@@ -1,10 +1,11 @@
 ---
-title: "Product Telemetry"
-description: "Learn how NGINX Gateway Fabric collects product telemetry to identify areas to focus development on improving."
+title: "Product telemetry"
 weight: 500
 toc: true
 ---
 
+Learn why, what and how NGINX Gateway Fabric collects telemetry.
+
 ## Overview
 
 NGINX Gateway Fabric collects telemetry by default, which allows its developers to understand what features are most popular with its user base. This data is used to triage development work, prioritizing features and functionality that will positively impact the most people.
diff --git a/site/content/overview/resource-validation.md b/site/content/overview/resource-validation.md
index 2483ef0151..533b64bb84 100644
--- a/site/content/overview/resource-validation.md
+++ b/site/content/overview/resource-validation.md
@@ -1,5 +1,5 @@
 ---
-title: "Resource Validation"
+title: "Resource validation"
 weight: 400
 toc: true
 docs: "DOCS-1414"
@@ -9,7 +9,7 @@ docs: "DOCS-1414"
 
 This document describes how NGINX Gateway Fabric validates Gateway API and NGINX Gateway Fabric Kubernetes resources.
 
-## Gateway API Resource Validation
+## Gateway API resource validation
 
 NGINX Gateway Fabric validates Gateway API resources for several reasons:
 
@@ -110,7 +110,7 @@ Status:
 
 {{< note>}}Make sure the reported observed generation is the same as the resource generation.{{< /note >}}
 
-## NGINX Gateway Fabric Resource Validation
+## NGINX Gateway Fabric Resource validation
 
 ### Step 1 - OpenAPI Scheme validation by Kubernetes API Server
 
diff --git a/site/content/reference/api.md b/site/content/reference/api.md
index b597e1a39e..d9dd3d2de2 100644
--- a/site/content/reference/api.md
+++ b/site/content/reference/api.md
@@ -1,9 +1,10 @@
 ---
-title: "API Reference"
-description: "NGINX Gateway API Reference"
+title: "API reference"
 weight: 100
 toc: false
 ---
+## Overview
+NGINX Gateway API Reference
 <p>Packages:</p>
 <ul>
 <li>
diff --git a/site/content/reference/cli-help.md b/site/content/reference/cli-help.md
index f40c1067ba..8f53f5c7e9 100644
--- a/site/content/reference/cli-help.md
+++ b/site/content/reference/cli-help.md
@@ -1,16 +1,19 @@
 ---
-title: "Command-line Reference Guide"
-description: "Learn about the commands available for the executable file of the NGINX Gateway Fabric container."
+title: "Command-line reference guide"
 weight: 100
 toc: true
 docs: "DOCS-1435"
 ---
 
-## Static Mode
+## Overview
+
+Learn about the commands available for the executable file of the NGINX Gateway Fabric container.
+
+## Static mode
 
 This command configures NGINX for a single NGINX Gateway Fabric resource.
 
-_Usage_:
+*Usage*:
 
 ```shell
   gateway static-mode [flags]
diff --git a/site/content/reference/technical-specifications.md b/site/content/reference/technical-specifications.md
index 03efd5fb68..bb403c0289 100644
--- a/site/content/reference/technical-specifications.md
+++ b/site/content/reference/technical-specifications.md
@@ -1,5 +1,5 @@
 ---
-title: "Technical Specifications"
+title: "Technical specifications"
 draft: false
 description: "NGINX Gateway Fabric technical specifications."
 weight: 200