diff --git a/site/docs/aquery.html b/site/docs/aquery.html
index cef6c25..a71d19d 100644
--- a/site/docs/aquery.html
+++ b/site/docs/aquery.html
@@ -1,24 +1,24 @@
 ---
 layout: documentation
-title: Aquery (Action Graph Query)
+title: Aquery (action graph query)
 ---
-<h1>Aquery (Action Graph Query)</h1>
+<h1>Aquery (action graph query)</h1>
 
 
 <ul>
   <li><a href="#overview">Overview</a></li>
-  <li><a href="#basic-syntax">Basic Syntax</a></li>
-  <li><a href="#functions">Aquery Functions</a></li>
+  <li><a href="#basic-syntax">Basic syntax</a></li>
+  <li><a href="#functions">Aquery functions</a></li>
   <li><a href="#options">Options</a></li>
   <li>
-    <a href="#misc">Other Tools and Features</a>
+    <a href="#misc">Other tools and features</a>
     <ul>
-      <li><a href="#skyframe-state">Querying Against the State of Skyframe</a></li>
-      <li><a href="#diff-tool">Comparing Aquery Outputs</a></li>
-      <li><a href="#aspect-on-aspect">Handling Aspect-on-aspect</a></li>
+      <li><a href="#skyframe-state">Querying against the state of Skyframe</a></li>
+      <li><a href="#diff-tool">Comparing qquery outputs</a></li>
+      <li><a href="#aspect-on-aspect">Handling aspect-on-aspect</a></li>
     </ul>
   </li>
-  <li><a href="#known-issues">Known Issues</a></li>
+  <li><a href="#known-issues">Known issues</a></li>
   <li><a href="#updates">Updates</a></li>
 </ul>
 
@@ -61,7 +61,7 @@
   Outputs: [...]
 </pre>
 
-<h2 id='basic-syntax'>Basic Syntax</h2>
+<h2 id='basic-syntax'>Basic syntax</h2>
 
 <p>A simple example of the syntax for <code>aquery</code> is as follows:</p>
 
@@ -96,7 +96,7 @@
 $ bazel aquery 'inputs(".*cpp", deps(//src/target_a))'
 </pre>
 
-<h2 id='functions'>Aquery Functions</h2>
+<h2 id='functions'>Aquery functions</h2>
 
 <p>There are currently 3 <code>aquery</code> functions:</p>
 <ul>
@@ -143,7 +143,7 @@
 
 <h2 id='options'>Options</h2>
 
-<h3>Build Options</h3>
+<h3>Build options</h3>
 
 <p>
   <code>aquery</code> runs on top of a regular Bazel build and thus inherits the set of
@@ -187,7 +187,7 @@
   This flag is only available with <code>--output=proto</code> or <code>--output=textproto</code>.
 </p>
 
-<h2 id='misc'>Other Tools and Features</h2>
+<h2 id='misc'>Other tools and features</h2>
 
 <h3 id="skyframe-state">Querying against the state of Skyframe</h3>
 
@@ -268,7 +268,7 @@
   $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java")'
 </pre>
 
-<h3 id="diff-tool">Comparing Aquery Outputs</h3>
+<h3 id="diff-tool">Comparing aquery outputs</h3>
 
 <p>
   You can compare the outputs of two different aquery invocations using the <code>aquery_differ</code> tool.
@@ -324,7 +324,7 @@
   to be compared.
 </p>
 
-<h3 id="aspect-on-aspect">Aspect-on-Aspect</h3>
+<h3 id="aspect-on-aspect">Aspect-on-aspect</h3>
 
 <p>
   It is possible for <a href="https://docs.bazel.build/versions/master/skylark/aspects.html">Aspects</a>
@@ -381,7 +381,7 @@
   <a href="https://docs.bazel.build/versions/master/skylark/aspects.html#aspect-basics">dependency graph</a>.
 </p>
 
-<h2 id='known-issues'>Known Issues</h2>
+<h2 id='known-issues'>Known issues</h2>
 
 <h3 id='shared-actions'>Handling Shared Actions</h3>
 
diff --git a/site/docs/backward-compatibility.md b/site/docs/backward-compatibility.md
index a3df992..6ab34f2 100644
--- a/site/docs/backward-compatibility.md
+++ b/site/docs/backward-compatibility.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Backward Compatibility
+title: Backward compatibility
 ---
 
-# Backward Compatibility
+# Backward compatibility
 
 Bazel is evolving, and we will make changes to Bazel that at times will be
 incompatible and require some changes from Bazel users.
diff --git a/site/docs/bazel-vision.md b/site/docs/bazel-vision.md
index ac515b2..7a3d4f7 100644
--- a/site/docs/bazel-vision.md
+++ b/site/docs/bazel-vision.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Bazel Vision
+title: Bazel vision
 ---
 
-# Bazel Vision
+# Bazel vision
 
 <p><font size='+1'>Any software developer can efficiently build, test, and package
 any project, of any size or complexity, with tooling that's easy to adopt and
@@ -46,7 +46,7 @@
 toolchains implemented in a simple extensibility language — allows it to be
 easily applied to any context.
 
-## Bazel Core Competencies
+## Bazel core competencies
 
 1.  Bazel supports **multi-language, multi-platform** builds and tests. You can
     run a single command to build and test your entire source tree, no matter
diff --git a/site/docs/build-event-protocol.md b/site/docs/build-event-protocol.md
index 4166946..54af179 100644
--- a/site/docs/build-event-protocol.md
+++ b/site/docs/build-event-protocol.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Build Event Protocol
+title: Build event protocol
 ---
 
-# Build Event Protocol
+# Build event protocol
 
 The [Build Event
 Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
@@ -20,17 +20,17 @@
 
 ## Contents
 
-*  [Build Event Protocol Overview](#build-event-protocol-overview)
-   *  [Build Event Graph](#build-event-graph)
-   *  [The Build Event Protocol by Example](#the-build-event-protocol-by-example)
+*  [Overview](#overview)
+   *  [Build event graph](#build-event-graph)
+   *  [The Build Event Protocol by example](#the-build-event-protocol-by-example)
 *  [Consuming the Build Event Protocol](#consuming-the-build-event-protocol)
-   *  [Consume in a Binary Format](#consume-in-a-binary-format)
-   *  [Consume in Text Formats](#consume-in-text-formats)
+   *  [Consume in a binary format](#consume-in-a-binary-format)
+   *  [Consume in text formats](#consume-in-text-formats)
 *  [The Build Event Service](#the-build-event-service)
-   *  [Build Event Service Flags](#build-event-service-flags)
-   *  [Authentication and Security](#authentication-and-security)
+   *  [Build Event Service flags](#build-event-service-flags)
+   *  [Authentication and aecurity](#authentication-and-security)
 
-## Build Event Protocol Overview
+## Overview
 
 The Build Event Protocol represents information about a build as events. A
 build event is a protocol buffer message consisting of a build event identifier,
@@ -56,7 +56,7 @@
 payload might not be the expected type, but could be an `Aborted` message e.g.
 if the build aborted prematurely.
 
-### Build Event Graph
+### Build event graph
 
 All build events form a directed acyclic graph through their parent and child
 relationship. Every build event except for the initial build event has one or
@@ -65,7 +65,7 @@
 all announced events will have been posted. In case of a Bazel crash or a failed
 network transport, some announced build events may never be posted.
 
-## The Build Event Protocol by Example
+## The Build Event Protocol by example
 
 The full specification of the Build Event Protocol can be found in its protocol
 buffer definition and describing it here is beyond the scope of this document.
@@ -161,7 +161,7 @@
 
 ## Consuming the Build Event Protocol
 
-### Consume in a Binary Format
+### Consume in a binary format
 
 To consume the Build Event Protocol in a binary format:
 
@@ -176,7 +176,7 @@
 2. Then, write a program that extracts the relevant information from the
 serialized protocol buffer message.
 
-### Consume in Text Formats
+### Consume in text formats
 
 The following Bazel command line flags will output the Build Event Protocol in a
 human-readable formats:
@@ -202,7 +202,7 @@
 Event Service](https://github.com/buildbarn/bb-event-service/) in Go as part of
 the Buildbarn suite of Remote Execution tools and services.
 
-### Build Event Service Flags
+### Build Event Service flags
 
 Bazel has several flags related to the Build Event Service protocol, including:
 
@@ -216,7 +216,7 @@
 For a description of each of these flags, see the
 [Command-Line Reference](command-line-reference.html).
 
-### Authentication and Security
+### Authentication and security
 
 Bazel’s Build Event Service implementation also supports authentication and TLS.
 These settings can be controlled using the below flags. Please note that these
@@ -233,7 +233,7 @@
 For a description of each of these flags, see the
 [Command-Line Reference](command-line-reference.html).
 
-### Build Event Service and Remote Caching
+### Build Event Service and remote caching
 
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
diff --git a/site/docs/build-ref.html b/site/docs/build-ref.html
index 973144f..54f2fa4 100644
--- a/site/docs/build-ref.html
+++ b/site/docs/build-ref.html
@@ -1,13 +1,13 @@
 ---
 layout: documentation
-title: Concepts and Terminology
+title: Concepts and terminology
 ---
-<h1>Concepts and Terminology</h1>
+<h1>Concepts and terminology</h1>
 <p>
   This document provides an overview of the source tree layout and the
   terminology used in Bazel.
 </p>
-<h2>Table of Contents</h2>
+<h2>Table of contents</h2>
 
 <ul>
   <li><a href="#intro">Introduction</a></li>
@@ -47,7 +47,7 @@
    of related source files and one BUILD file. The BUILD file specifies what
    software outputs can be built from the source.
 </p>
-<h2 id="packages_targets">Workspace, Packages and Targets</h2>
+<h2 id="packages_targets">Workspace, packages and targets</h2>
 <h3 id="workspace">Workspace</h3>
 
 <p>A <em>workspace</em> is a directory on your filesystem that contains the
@@ -464,7 +464,7 @@
 </p>
 
 
-<h2 id="BUILD_files">BUILD Files</h2>
+<h2 id="BUILD_files">BUILD files</h2>
 
 <p>
   The previous section described packages, targets and labels, and the
@@ -961,7 +961,7 @@
 path, e.g.
 
 <code>${TEST_SRCDIR}/workspace/path/to/data/file</code>.
-   <h3 id="label_directory">Using Labels to Reference Directories</h3>
+   <h3 id="label_directory">Using labels to reference directories</h3>
 
    <p>As you look over our <code>BUILD</code> files, you might notice
       that some <code>data</code> labels refer to directories.
diff --git a/site/docs/completion.md b/site/docs/completion.md
index a5129d7..35bfb2a 100644
--- a/site/docs/completion.md
+++ b/site/docs/completion.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: "Command-Line Completion"
+title: Command-line completion
 ---
 
-# Command-Line Completion
+# Command-line completion
 
 You can enable command-line completion (also known as tab-completion) in Bash
 and Zsh. This lets you tab-complete command names, flags names and flag values,
diff --git a/site/docs/configurable-attributes.md b/site/docs/configurable-attributes.md
index 4ecf439..8583f5d 100644
--- a/site/docs/configurable-attributes.md
+++ b/site/docs/configurable-attributes.md
@@ -1,25 +1,25 @@
 ---
 layout: documentation
-title: Configurable Build Attributes
+title: Configurable build attributes
 ---
 
-# Configurable Build Attributes
+# Configurable build attributes
 
 ### Contents
 * [Example](#example)
-* [Configuration Conditions](#configuration-conditions)
+* [Configuration conditions](#configuration-conditions)
 * [Defaults](#defaults)
-* [Custom Keys](#custom-keys)
+* [Custom keys](#custom-keys)
 * [Platforms](#platforms)
-* [Short Keys](#short-keys)
-* [Multiple Selects](#multiple-selects)
-* [OR Chaining](#or-chaining)
+* [Short keys](#short-keys)
+* [Multiple `select` functions](#multiple-select-functions)
+* [OR chaining](#or-chaining)
   * [selects.with_or](#selects-with-or)
   * [selects.config_setting_group](#selects-config-setting-or-group)
-* [AND Chaining](#and-chaining)
-* [Custom Error Messages](#custom-error-messages)
-* [Rules Compatibility](#rules)
-* [Bazel Query and Cquery](#query)
+* [AND chaining](#and-chaining)
+* [Custom error messages](#custom-error-messages)
+* [Rules compatibility](#rules)
+* [Bazel query and query](#query)
 * [FAQ](#faq)
   * [Why doesn't select() work in macros?](#macros-select)
   * [Why does select() always return true?](#boolean-select)
@@ -116,7 +116,7 @@
 but not within the attribute that causes the change. That is, a `select` in the
 `tools` attribute of a `genrule` will work the same as a `select` in the `srcs`.
 
-## Configuration Conditions
+## Configuration conditions
 
 Each key in a configurable attribute is a label reference to a
 [`config_setting`](be/general.html#config_setting) target. This is just a
@@ -195,7 +195,7 @@
 `select()` can include a [`no_match_error`](#custom-error-messages) for custom
 failure messages.
 
-## Custom Keys
+## Custom keys
 
 Since `config_setting` currently only supports built-in Bazel flags, the level
 of custom conditioning it can support is limited. For example, there's no Bazel
@@ -327,7 +327,7 @@
 Platforms are still under development. See the [documentation](platforms.html)
 and [roadmap](https://bazel.build/roadmaps/platforms.html) for details.
 
-## Short Keys
+## Short keys
 
 Since configuration keys are target labels, their names can get long and
 unwieldy. This can be mitigated with local variable definitions:
@@ -409,7 +409,7 @@
 )
 ```
 
-## Multiple Selects
+## Multiple `select` functions
 
 `select` can appear multiple times in the same attribute:
 
@@ -456,7 +456,7 @@
 If you just need a `select` to match when multiple conditions match, see [AND
 chaining](#and-chaining).
 
-## OR Chaining
+## OR chaining
 
 Consider the following:
 
@@ -566,7 +566,7 @@
 "specialization" of the other. See [select()](be/functions.html#select)
 documentation for details.
 
-## And Chaining
+## And chaining
 
 If you need a `select` path to match when multiple conditions match, use the
 [Skylib](https://github.com/bazelbuild/bazel-skylib) macro
@@ -603,7 +603,7 @@
 directly inside a `select`: you have to explicitly declare the
 `config_setting_group`.
 
-## Custom Error Messages
+## Custom error messages
 
 By default, when no condition matches, the owning target fails with the error:
 
@@ -636,7 +636,7 @@
 build with an Android or Windows toolchain
 ```
 
-## <a name="rules"></a>Rules Compatibility
+## <a name="rules"></a>Rules compatibility
 Rule implementations receive the *resolved values* of configurable
 attributes. For example, given:
 
@@ -683,7 +683,7 @@
 technically feasible, lack a coherent UI. Further design is necessary to change
 this.
 
-## <a name="query"></a>Bazel Query and Cquery
+## <a name="query"></a>Bazel query and cquery
 Bazel `query` operates over Bazel's [loading phase](
 user-manual.html#loading-phase). This means it doesn't know what command line
 flags will be applied to a target since those flags aren't evaluated until later
diff --git a/site/docs/cquery.html b/site/docs/cquery.html
index 0ec6e18..15969c1 100644
--- a/site/docs/cquery.html
+++ b/site/docs/cquery.html
@@ -2,16 +2,16 @@
 layout: documentation
 title: Cquery (configurable query)
 ---
-<h1>Cquery (Configurable Query)</h1>
+<h1>Cquery (configurable query)</h1>
 
 <ul class="toc">
   <li><a href="#overview">Overview</a></li>
-  <li><a href="#basic-syntax">Basic Syntax</a></li>
-  <li><a href="#target-pattern-evaluation">Target Pattern Evaluation</a></li>
+  <li><a href="#basic-syntax">Basic syntax</a></li>
+  <li><a href="#target-pattern-evaluation">Target pattern evaluation</a></li>
   <li><a href="#functions">Functions</a></li>
   <li><a href="#options">Options</a></li>
   <li><a href="#compare">cquery vs. query</a></li>
-  <li><a href="#known-issues">Known Issues</a></li>
+  <li><a href="#known-issues">Known issues</a></li>
   <li><a href="#updates">Updates</a></li>
 </ul>
 
@@ -92,7 +92,7 @@
   see <code><a href="aquery.html">aquery</a></code>.
 </p>
 
-<h2 id='basic-syntax'>Basic Syntax</h2>
+<h2 id='basic-syntax'>Basic syntax</h2>
 
 <p>A simple <code>cquery</code> call looks like:</p>
 
@@ -123,7 +123,7 @@
   for querying dependencies of top-level build targets.
 </p>
 
-<h2 id='target-pattern-evaluation'>Target Pattern Evaluation</h2>
+<h2 id='target-pattern-evaluation'>Target pattern evaluation</h2>
 
 <p>
   <code>//foo</code> has a different meaning for <code>cquery</code> than
@@ -221,7 +221,7 @@
 
 <h2 id='options'>Options</h2>
 
-<h3>Build Options</h3>
+<h3>Build options</h3>
 
 <p>
   <code>cquery</code> runs over a regular Bazel build and thus inherits the
@@ -324,7 +324,7 @@
   targets also in non-target configurations.
 </p>
 
-<h2 id='output-formats'>Output Formats</h2>
+<h2 id='output-formats'>Output formats</h2>
 
 <p> By default, cquery outputs results in a dependency-ordered list of label and configuration pairs.
 There are other options for exposing the results as well. </p>
@@ -419,12 +419,12 @@
    </li>
    <li>
       As a newer tool, <code>cquery</code> lacks support for certain use
-      cases. See <a href="#known-issues">Known Issues</a> for details.
+      cases. See <a href="#known-issues">Known issues</a> for details.
    </li>
   </ul>
 </p>
 
-<h2 id='known-issues'>Known Issues</h2>
+<h2 id='known-issues'>Known issues</h2>
 
 <ul>
   <li>
diff --git a/site/docs/external.md b/site/docs/external.md
index c45a809..4053512 100644
--- a/site/docs/external.md
+++ b/site/docs/external.md
@@ -1,6 +1,6 @@
 ---
 layout: documentation
-title: External Dependencies
+title: External dependencies
 ---
 
 # Working with external dependencies
@@ -229,7 +229,7 @@
 
 
 <a name="using-proxies"></a>
-## Using Proxies
+## Using proxies
 
 Bazel will pick up proxy addresses from the `HTTPS_PROXY` and `HTTP_PROXY`
 environment variables and use these to download HTTP/HTTPS files (if specified).
diff --git a/site/docs/getting-started.md b/site/docs/getting-started.md
index a858100..7e023cb 100644
--- a/site/docs/getting-started.md
+++ b/site/docs/getting-started.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Getting Started
+title: Getting started
 ---
 
-# Getting Started with Bazel
+# Getting started with Bazel
 
 This page lists material that will help you get started with Bazel. If you have
 not already done so, first read the [Bazel Overview](bazel-overview.html).
diff --git a/site/docs/guide.html b/site/docs/guide.html
index e4376af..3a51aa8 100644
--- a/site/docs/guide.html
+++ b/site/docs/guide.html
@@ -1,8 +1,8 @@
 ---
 layout: documentation
-title: User's Guide
+title: User's guide
 ---
-<h1>A User's Guide to Bazel</h1>
+<h1>A user's guide to Bazel</h1>
 
 
 <p>
diff --git a/site/docs/install.md b/site/docs/install.md
index ce631e1..6c11627 100644
--- a/site/docs/install.md
+++ b/site/docs/install.md
@@ -11,7 +11,7 @@
 *   [macOS](install-os-x.md)
 *   [Windows](install-windows.md)
 
-## Community-Supported Packages
+## Community-supported packages
 
 *   [Arch Linux](https://www.archlinux.org/packages/community/x86_64/bazel/)
 *   [Fedora 25, 26, 27, 28, and CentOS 7](install-redhat.md)
@@ -23,7 +23,7 @@
 *   [Parabola](https://www.parabola.nu/packages/?q=bazel)
 *   [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json)
 
-## Community-Supported Architectures
+## Community-supported architectures
 *   [ppc64le](https://oplab9.parqtec.unicamp.br/pub/ppc64el/bazel)
 
 
diff --git a/site/docs/output_directories.md b/site/docs/output_directories.md
index 068a9b7..bdb7a3f 100644
--- a/site/docs/output_directories.md
+++ b/site/docs/output_directories.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Output Directory Layout
+title: Output directory layout
 ---
 
-# Output Directory Layout
+# Output directory layout
 
 ## Requirements
 
@@ -20,7 +20,7 @@
 * All the build state per user should be underneath one directory ("I'd like to
   clean all the .o files from all my clients.")
 
-## Documentation of the current Bazel output directory layout
+## Current layout
 
 The solution that's currently implemented:
 
@@ -55,7 +55,7 @@
 These symlinks are only for the user's convenience, as Bazel itself does not
 use them. Also, we only do this if the workspace directory is writable.
 
-## Bazel internals: Directory layout
+## Layout diagram
 
 The directories are laid out as follows:
 
diff --git a/site/docs/platforms-intro.md b/site/docs/platforms-intro.md
index 47e7b84..5ac653d 100644
--- a/site/docs/platforms-intro.md
+++ b/site/docs/platforms-intro.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Building With Platforms
+title: Building with platforms
 ---
 
-# Building With Platforms
+# Building with platforms
 
 - [Overview](#overview)
 - [Background](#background)
diff --git a/site/docs/query-how-to.html b/site/docs/query-how-to.html
index 22d66b9..6dfc4d3 100644
--- a/site/docs/query-how-to.html
+++ b/site/docs/query-how-to.html
@@ -1,6 +1,6 @@
 ---
 layout: documentation
-title: Bazel Query How-To
+title: Bazel query how-to
 ---
 <h1>Bazel query how-to</h1>
 
@@ -21,12 +21,12 @@
 <h2>Contents</h2>
 
 <ul>
-<li><a href="#Finding_the_Dependencies_of_a_Ru">Finding the Dependencies of a Rule</a></li>
-<li><a href="#Tracing_the_Dependency_Chain_bet">Tracing the Dependency Chain between Two
-Packages</a>
+<li><a href="#Finding_the_Dependencies_of_a_Ru">Finding the dependencies of a rule</a></li>
+<li><a href="#Tracing_the_Dependency_Chain_bet">Tracing the dependency chain between two
+packages</a>
 <ul><li><a href="#Aside_implicit_dependencies">Aside: implicit dependencies</a></li></ul></li>
-<li><a href="#Reverse_Dependencies">Reverse Dependencies</a></li>
-<li><a href="#Miscellaneous_Uses">Miscellaneous Uses</a>
+<li><a href="#Reverse_Dependencies">Reverse dependencies</a></li>
+<li><a href="#Miscellaneous_Uses">Miscellaneous uses</a>
 <ul><li><a href="#What_exists_">What exists ...</a>
 <ul><li><a href="#What_packages_exist_beneath_foo_">What packages exist beneath
 <code>foo</code>?</a></li>
@@ -100,7 +100,7 @@
 build?</a></li></ul></li></ul></li>
 </ul>
 
-<h2 id="Finding_the_Dependencies_of_a_Ru">Finding the Dependencies of a Rule</h2>
+<h2 id="Finding_the_Dependencies_of_a_Ru">Finding the dependencies of a rule</h2>
 
 <p>To see the dependencies of <code>//foo</code>, use the
 <code>deps</code> function in bazel query:</p>
@@ -114,7 +114,7 @@
 
 <p>This is the set of all targets required to build <code>//foo</code>.</p>
 
-<h2 id="Tracing_the_Dependency_Chain_bet">Tracing the Dependency Chain between Two Packages</h2>
+<h2 id="Tracing_the_Dependency_Chain_bet">Tracing the dependency chain between two packages</h2>
 
 <p>The library <code>//third_party/zlib:zlibonly</code> isn't in the BUILD file for
 <code>//foo</code>, but it is an indirect dependency. How can
@@ -188,7 +188,7 @@
   currently undocumented. Using <code>--noimplicit_deps</code> allows you to filter out
   these deps from your query results.
 
-<h2 id="Reverse_Dependencies">Reverse Dependencies</h2>
+<h2 id="Reverse_Dependencies">Reverse dependencies</h2>
 
 <p>You might want to know the set of targets that depends on some target.  e.g.,
 if you're going to change some code, you might want to know what other code
@@ -198,7 +198,7 @@
 Bazel's <a href="query.html#sky-query">Sky Query</a>
 supports the <code>allrdeps</code> function which allows you to query rdeps in the entire
 universe of the build.
-<h2 id="Miscellaneous_Uses">Miscellaneous Uses</h2>
+<h2 id="Miscellaneous_Uses">Miscellaneous uses</h2>
 
 <p>You can use <code>bazel query</code> to analyze many dependency relationships.</p>
 
diff --git a/site/docs/query.html b/site/docs/query.html
index 53e0670..d9d1810 100644
--- a/site/docs/query.html
+++ b/site/docs/query.html
@@ -1,17 +1,17 @@
 ---
 layout: documentation
-title: Query Language
+title: Query language
 ---
-<h1>The Bazel Query Reference</h1>
+<h1>The Bazel query reference</h1>
 
 
 <ul class="toc">
   <li><a href="query.html#examples">Examples</a></li>
-  <li><a href="query.html#tokens">Tokens: The Lexical Syntax</a></li>
-  <li><a href="query.html#concepts">Bazel Query Language Concepts</a></li>
-  <li><a href="query.html#expressions">Expressions: Syntax and Semantics of the Grammar</a></li>
+  <li><a href="query.html#tokens">Tokens: The lexical syntax</a></li>
+  <li><a href="query.html#concepts">Bazel query language concepts</a></li>
+  <li><a href="query.html#expressions">Expressions: Syntax and semantics of the grammar</a></li>
   <li><a href="query.html#functions">Functions</a></li>
-  <li><a href="query.html#output-formats">Output Formats</a></li>
+  <li><a href="query.html#output-formats">Output formats</a></li>
 </ul>
 
 <p>
@@ -51,7 +51,7 @@
   <pre>kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))</pre>
 
 
-<h2 id='tokens'>Tokens: The Lexical Syntax</h2>
+<h2 id='tokens'>Tokens: The lexical syntax</h2>
 
 <p>
   Expressions in the query language are composed of the following
@@ -149,7 +149,7 @@
   Whitespace characters outside of a quoted word are ignored.
 </p>
 
-<h2 id='concepts'>Bazel Query Language Concepts</h2>
+<h2 id='concepts'>Bazel query language concepts</h2>
 <p>
   The Bazel query language is a language of expressions.  Every
   expression evaluates to a <b>partially-ordered set</b> of targets,
@@ -262,7 +262,7 @@
   <code>dir/...</code>, etc.
 </p>
 
-<h3 id='sky-query'>Sky Query</h3>
+<h3 id='sky-query'>Sky query</h3>
 
 <p>
   Query has two different implementations, with slightly different features. The alternative one is
@@ -287,7 +287,7 @@
   it is faster and uses less memory.
 </p>
 
-<h2 id='expressions'>Expressions: Syntax and Semantics of the Grammar</h2>
+<h2 id='expressions'>Expressions: Syntax and semantics of the grammar</h2>
 
 <p>
   This is the grammar of the Bazel query language, expressed in EBNF
@@ -1103,7 +1103,7 @@
   .bzl files that are referenced from its BUILD files.
 </p>
 
-<h2 id='output-formats'>Output Formats</h2>
+<h2 id='output-formats'>Output formats</h2>
 
 <p>
   <code>bazel query</code> generates a graph.
diff --git a/site/docs/remote-caching-debug.md b/site/docs/remote-caching-debug.md
index 46d0e77..01f25d6 100644
--- a/site/docs/remote-caching-debug.md
+++ b/site/docs/remote-caching-debug.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Debugging Remote Cache Hits for Local Execution
+title: Debugging remote cache hits for local execution
 ---
 
-# Debugging Remote Cache Hits for Local Execution
+# Debugging remote cache hits for local execution
 
 This page describes how to investigate cache misses in the context of local
 execution.
diff --git a/site/docs/remote-caching.md b/site/docs/remote-caching.md
index 47b9853..1479847 100644
--- a/site/docs/remote-caching.md
+++ b/site/docs/remote-caching.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Remote Caching
+title: Remote caching
 ---
 
-# Remote Caching
+# Remote caching
 
 A remote cache is used by a team of developers and/or a continuous integration
 (CI) system to share build outputs. If your build is reproducible, the
@@ -12,7 +12,7 @@
 
 ## Contents
 
-* [Remote caching overview](#remote-caching-overview)
+* [Overview](#overview)
 * [How a build uses remote caching](#how-a-build-uses-remote-caching)
 * [Setting up a server as the cache's backend](#setting-up-a-server-as-the-caches-backend)
     * [nginx](#nginx)
@@ -30,7 +30,7 @@
 * [Known Issues](#known-issues)
 * [External Links](#external-links)
 
-## Remote caching overview
+## Overview
 
 Bazel breaks a build into discrete steps, which are called actions. Each action
 has inputs, output names, a command line, and environment variables. Required
diff --git a/site/docs/remote-execution-caching-debug.md b/site/docs/remote-execution-caching-debug.md
index 6d00f53..7598d35 100644
--- a/site/docs/remote-execution-caching-debug.md
+++ b/site/docs/remote-execution-caching-debug.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Debugging Remote Cache Hits for Remote Execution
+title: Debugging remote cache hits for remote execution
 ---
 
-# Debugging Remote Cache Hits for Remote Execution
+# Debugging remote cache hits for remote execution
 
 This page describes how to check your cache hit rate and how to investigate
 cache misses in the context of remote execution.
@@ -40,7 +40,7 @@
 
 If you are not getting the cache hit rate you are expecting, do the following:
 
-### Ensure re-running the same build/test command produces cache hits.
+### Ensure re-running the same build/test command produces cache hits
 
 1. Run the build(s) and/or test(s) that you expect to populate the cache. The
    first time a new build is run on a particular stack, we expect no remote
diff --git a/site/docs/remote-execution-ci.md b/site/docs/remote-execution-ci.md
index 79c8d23..d856c03 100644
--- a/site/docs/remote-execution-ci.md
+++ b/site/docs/remote-execution-ci.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Configuring Bazel CI for Testing Rules Against Remote Execution
+title: Configuring Bazel CI for testing rules against remote execution
 ---
 
-# Configuring Bazel CI to Test Bazel Rules for Remote Execution
+# Configuring Bazel CI to test Bazel rules for remote execution
 
 *  [Overview](#overview)
 *  [Prerequisites](#prerequisites)
diff --git a/site/docs/remote-execution-rules.md b/site/docs/remote-execution-rules.md
index ee3ac2f..04e1caf 100644
--- a/site/docs/remote-execution-rules.md
+++ b/site/docs/remote-execution-rules.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Adapting Bazel Rules for Remote Execution
+title: Adapting Bazel rules for remote execution
 ---
 
-# Adapting Bazel Rules for Remote Execution
+# Adapting Bazel rules for remote execution
 
 Remote execution allows Bazel to execute actions on a separate platform, such as
 a datacenter. A [gRPC protocol](https://github.com/googleapis/googleapis/blob/master/google/devtools/remoteexecution/v1test/remote_execution.proto)
diff --git a/site/docs/remote-execution-sandbox.md b/site/docs/remote-execution-sandbox.md
index c828fcf..6ea2af5 100644
--- a/site/docs/remote-execution-sandbox.md
+++ b/site/docs/remote-execution-sandbox.md
@@ -1,10 +1,10 @@
 ---
 layout: documentation
-title: Troubleshooting Bazel Remote Execution with Docker Sandbox
+title: Troubleshooting Bazel remote execution with Docker sandbox
 
 ---
 
-# Troubleshooting Bazel Remote Execution with Docker Sandbox
+# Troubleshooting Bazel remote execution with Docker sandbox
 
 ## Contents
 
diff --git a/site/docs/remote-execution.md b/site/docs/remote-execution.md
index 491ee63..e1b176a 100644
--- a/site/docs/remote-execution.md
+++ b/site/docs/remote-execution.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Remote Execution Overview
+title: Remote execution overview
 ---
 
-# Remote Execution Overview
+# Remote execution overview
 
 By default, Bazel executes builds and tests on your local machine. Remote
 execution of a Bazel build allows you to distribute build and test actions
@@ -20,7 +20,7 @@
 [gRPC protocol](https://github.com/bazelbuild/remote-apis)
 to allow for remote execution and remote caching.
 
-## Remote Execution Services
+## Remote execution services
 
 To run Bazel with remote execution, you can use one of the following:
 
@@ -43,7 +43,7 @@
         To begin using the service, fill out this
         [short information form](https://docs.google.com/forms/d/e/1FAIpQLScBai-iQ2tn7RcGcsz3Twjr4yDOeHowrb6-3v5qlgS69GcxbA/viewform).
 
-## Requirements for Remote Execution
+## Requirements
 
 Remote execution of Bazel builds imposes a set of mandatory configuration
 constraints on the build. For more information, see
diff --git a/site/docs/skylark/build-style.md b/site/docs/skylark/build-style.md
index ec5449d..63b5eac 100644
--- a/site/docs/skylark/build-style.md
+++ b/site/docs/skylark/build-style.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: BUILD Style Guide
+title: BUILD style guide
 ---
 
-# BUILD Style Guide
+# BUILD style guide
 
 
 In `BUILD` files, we take the same approach as in Go: We let the machine take care
diff --git a/site/docs/skylark/bzl-style.md b/site/docs/skylark/bzl-style.md
index d085991..dfc7841 100644
--- a/site/docs/skylark/bzl-style.md
+++ b/site/docs/skylark/bzl-style.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: .bzl Style Guide
+title: .bzl style guide
 ---
 
-# .bzl Style Guide
+# .bzl style guide
 
 [Starlark](language.md) is a language that defines how software is built, and as
 such it is both a programming and a configuration language.
diff --git a/site/docs/skylark/concepts.md b/site/docs/skylark/concepts.md
index 77c5288..fdcc509 100644
--- a/site/docs/skylark/concepts.md
+++ b/site/docs/skylark/concepts.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Extension Overview
+title: Extension overview
 ---
 
-# Extension Overview
+# Extension overview
 
 <!-- [TOC] -->
 
diff --git a/site/docs/skylark/config.md b/site/docs/skylark/config.md
index cadf03d..fd61985 100644
--- a/site/docs/skylark/config.md
+++ b/site/docs/skylark/config.md
@@ -1,22 +1,21 @@
 ---
 layout: documentation
-title: Starlark Build Configurations
+title: Configuratios
 ---
 
-# Starlark Build Configurations
+# Configurations
 
 - [Overview](#overview)
-- [Current Status](#current-status)
-- [User-defined Build Settings](#user-defined-build-settings)
-- [Build Settings and Select](#build-settings-and-select)
-- [User-defined Transitions](#user-defined-transitions)
-- [Integration With Platforms and Toolchains](#integration-with-platforms-and-toolchains)
-- [Also See](#also-see)
+- [Current status](#current-status)
+- [User-defined build settings](#user-defined-build-settings)
+- [Build settings and the `select` function](#build-settings-and-the-select-function)
+- [User-defined transitions](#user-defined-transitions)
+- [Integration With platforms and toolchains](#integration-with-platforms-and-toolchains)
+- [Also see](#also-see)
 
 ## Overview
 
-Starlark build configuration is Bazel's API for customizing how your project
-builds.
+Starlark configuration is Bazel's API for customizing how your project builds.
 
 This makes it possible to:
 
@@ -33,7 +32,7 @@
 
 <!-- [TOC] -->
 
-## Current Status
+## Current status
 
 As of Q4'19, everything documented here works but
 may have memory and performance consequences as we work on scaling concerns.
@@ -48,7 +47,7 @@
 *   [#5578](https://github.com/bazelbuild/bazel/issues/5578) - Configuration
     doesn't block native to Skylark rules migration
 
-## User-defined Build Settings
+## User-defined build settings
 A build setting is a single piece of
 [configuration](rules.html#configurations)
 information. Think of a configuration as a key/value map. Setting `--cpu=ppc`
@@ -65,9 +64,9 @@
 (if they're designated as `flags`, see more below), but can also be
 set via [user-defined transitions](#user-defined-transitions).
 
-### Defining Build Settings
+### Defining build settings
 
-#### The `build_setting` `rule()` Parameter
+#### The `build_setting` `rule()` parameter
 
 Build settings are rules like any other rule and are differentiated using the
 Starlark `rule()` function's `build_setting`
@@ -164,9 +163,9 @@
 A collection of the most common build setting rules can be found in
 [skylib](https://github.com/bazelbuild/bazel-skylib/blob/master/rules/common_settings.bzl).
 
-### Using Build Settings
+### Using build settings
 
-#### Depending on Build Settings
+#### Depending on build settings
 If a target would like to read a piece of configuration information, it can
 directly depend on the build setting via a regular attribute dependency.
 
@@ -253,7 +252,7 @@
 $ bazel build //my/target --//third_party/bazel/src/main:cpu=k8 --no//my/project:boolean_flag
 ```
 
-### Label-typed Build Settings
+### Label-typed build settings
 
 Unlike other build settings, label-typed settings cannot be defined using the
 `build_setting` rule parameter. Instead, bazel has two built-in rules:
@@ -307,7 +306,7 @@
 
 TODO(bazel-team): Expand supported build setting types.
 
-## Build Settings and Select
+## Build settings and the `select` function
 
 Users can configure attributes on build settings by using
  [`select()`](../be/functions.html#select). Build setting targets can be passed to the `flag_values` attribute of
@@ -324,7 +323,7 @@
 ```
 
 
-## User-defined Transitions
+## User-defined transitions
 
 A configuration
 [transition](lib/transition.html#transition)
@@ -348,7 +347,7 @@
 > Contact bazel-discuss@googlegroups.com if you'd like advice or assistance
 > understanding how transitions can affect on your build performance.
 
-### Defining Transitions in Starlark
+### Defining
 
 Transitions define configuration changes between rules. For example, a request
 like "compile my dependency for a different CPU than its parent" is handled by a
@@ -407,7 +406,7 @@
 not actually changed over the course of the transition - its original value must
 be explicitly passed through in the returned dictionary.
 
-#### Defining 1:2+ Transitions
+#### Defining 1:2+ transitions
 [Outgoing edge transition](#outgoing-edge-transitions) can map a single input
 configuration to two or more output configurations. These are defined in
 Starlark by returning a list of dictionaries in the transition implementation
@@ -429,7 +428,7 @@
 )
 ```
 
-### Attaching Transitions
+### Attaching transitions
 Transitions can be attached in two places: incoming edges and outgoing edges.
 Effectively this means rules can transition their own configuration (incoming
 edge transition) and transition their dependencies' configurations (outgoing
@@ -440,7 +439,7 @@
 bazel-discuss@googlegroups.com
 and we can help you try to figure out a workaround.
 
-#### Incoming Edge Transitions
+#### Incoming edge transitions
 Incoming edge transitions are activated by attaching a `transition` object
 (created by `transition()`) to `rule()`'s `cfg` parameter:
 
@@ -455,7 +454,7 @@
 
 Incoming edge transitions must be 1:1 transitions.
 
-### Outgoing Edge Transitions
+### Outgoing edge transitions
 Outgoing edge transitions are activated by attaching a `transition` object
 (created by `transition()`) to an attribute's `cfg` parameter:
 
@@ -469,7 +468,7 @@
 ```
 Outgoing edge transitions can be 1:1 or 1:2+.
 
-### Transitions on Native Options
+### Transitions on native options
 WARNING: This feature will be deprecated soon. Use at your own risk.
 
 Starlark transitions can also declare reads and writes on native options via
@@ -487,7 +486,7 @@
     outputs = ["//command_line_option:cpu"]
 ```
 
-### Accessing Attributes with Transitions
+### Accessing attributes with transitions
 When [attaching a transition to an outgoing edge](#outgoing-edge-transitions)
 (regardless of whether the transition is a 1:1 or 1:2+ transition) access to
 values of that attribute in the rule implementation changes. Access through
@@ -525,13 +524,13 @@
 Access to the value of a single branch of a 1:2+
 [has not been implemented yet](https://github.com/bazelbuild/bazel/issues/8633).
 
-## Integration with Platforms and Toolchains
+## Integration with platforms and toolchains
 Many native flags today, like `--cpu` and `--crosstool_top` are related to
 toolchain resolution. In the future, explicit transitions on these types of
 flags will likely be replaced by transitioning on the
 [target platform](../platforms.html)
 
-## Also See:
+## Also see:
 
  * [Starlark Build Configuration](https://docs.google.com/document/d/1vc8v-kXjvgZOdQdnxPTaV0rrLxtP2XwnD2tAZlYJOqw/edit?usp=sharing)
  * [Bazel Configurability Roadmap](https://bazel.build/roadmaps/configuration.html)
diff --git a/site/docs/skylark/deploying.md b/site/docs/skylark/deploying.md
index 21c4d3f..ab1d2b3 100644
--- a/site/docs/skylark/deploying.md
+++ b/site/docs/skylark/deploying.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Deploying Rules
+title: Deploying rules
 ---
 
-# Deploying Rules
+# Deploying rules
 
 This documentation is for rule writers who are planning to make their
 rules available to others.
diff --git a/site/docs/skylark/faq.md b/site/docs/skylark/faq.md
index d90bc95..ca95db7 100644
--- a/site/docs/skylark/faq.md
+++ b/site/docs/skylark/faq.md
@@ -3,7 +3,7 @@
 title: Extension FAQ
 ---
 
-# Frequently Asked Questions
+# Frequently asked questions
 
 These are some common issues and questions with writing extensions.
 
diff --git a/site/docs/skylark/language.md b/site/docs/skylark/language.md
index fd6710e..7439e37 100644
--- a/site/docs/skylark/language.md
+++ b/site/docs/skylark/language.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Starlark Language
+title: Starlark language
 ---
 
-# Starlark Language
+# Starlark language
 
 <!-- [TOC] -->
 
diff --git a/site/docs/skylark/performance.md b/site/docs/skylark/performance.md
index 5f7c9ef..9126f59 100644
--- a/site/docs/skylark/performance.md
+++ b/site/docs/skylark/performance.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Optimizing Performance
+title: Optimizing performance
 ---
 
-# Optimizing Performance
+# Optimizing performance
 
 When writing rules, the most common performance pitfall is to traverse or copy
 data that is accumulated from dependencies. When aggregated over the whole
@@ -357,7 +357,7 @@
 profile files small enough to render fast in the Chrome Trace Viewer.
 
 
-## Memory Profiling
+## Memory profiling
 
 Bazel comes with a built-in memory profiler that can help you check your rule's
 memory use. If there is a problem you can dump the heap to find the
diff --git a/site/docs/skylark/repository_rules.md b/site/docs/skylark/repository_rules.md
index 538927e..c67f513 100644
--- a/site/docs/skylark/repository_rules.md
+++ b/site/docs/skylark/repository_rules.md
@@ -1,8 +1,8 @@
 ---
 layout: documentation
-title: Repository Rules
+title: Repository rules
 ---
-# Repository Rules
+# Repository rules
 
 An [external repository](../external.md) is a rule that can be used only
 in the `WORKSPACE` file and enables non-hermetic operation at the loading phase
@@ -11,7 +11,7 @@
 libraries (such as Maven packaged libraries) but also to generate BUILD files
 specific to the host Bazel is running on.
 
-## Repository Rule creation
+## Repository rule creation
 
 In a `.bzl` file, use the
 [repository_rule](lib/globals.html#repository_rule) function to create a new
diff --git a/site/docs/skylark/rules.md b/site/docs/skylark/rules.md
index 08eb077..7b1bef6 100644
--- a/site/docs/skylark/rules.md
+++ b/site/docs/skylark/rules.md
@@ -133,7 +133,7 @@
 
 <a name="private-attributes"></a>
 
-### Private Attributes and Implicit Dependencies
+### Private attributes and implicit dependencies
 
 A dependency attribute with a default value is called an *implicit dependency*.
 The name comes from the fact that it is a part of the target graph that the user
@@ -398,7 +398,7 @@
 
 <a name="fragments"></a>
 
-## Configuration Fragments
+## Configuration fragments
 
 Rules may access [configuration fragments](lib/skylark-configuration-fragment.html)
 such as `cpp`, `java` and `jvm`. However, all required fragments must be
@@ -479,7 +479,7 @@
 * [providers with depsets](https://github.com/bazelbuild/examples/blob/master/rules/depsets/foo.bzl)
     This examples shows how a library and a binary rule can pass information.
 
-### Migrating from Legacy Providers
+### Migrating from legacy providers
 
 Historically, Bazel providers were simple fields on the `Target` object. They
 were accessed using the dot operator, and they were created by putting the field
diff --git a/site/docs/skylark/testing.md b/site/docs/skylark/testing.md
index 0d4cce8..433ebd1 100644
--- a/site/docs/skylark/testing.md
+++ b/site/docs/skylark/testing.md
@@ -179,7 +179,7 @@
 Note that the labels of all targets can conflict with other labels in the same
 BUILD package, so it's helpful to use a unique name for the test.
 
-### Failure Testing
+### Failure testing
 
 It may be useful to verify that a rule fails given certain inputs or in certain
 state. This can be done using the analysis test framework:
@@ -220,7 +220,7 @@
 # ":failure_testing_test" to the suite's test targets.
 ```
 
-### Verifying Registered Actions
+### Verifying registered actions
 
 You may want to write tests which make assertions about the actions that your
 rule registers, for example, using `ctx.actions.run()`. This can be done in your
@@ -243,7 +243,7 @@
 [`Action`](lib/Action.html) objects which represent actions registered by the
 target under test.
 
-### Verifying Rule Behavior Under Different Flags
+### Verifying rule behavior under different flags
 
 You may want to verify your real rule behaves a certain way given certain build
 flags. For example, your rule may behave differently if a user specifies:
diff --git a/site/docs/skylark/tutorial-creating-a-macro.md b/site/docs/skylark/tutorial-creating-a-macro.md
index b241070..20c3592 100644
--- a/site/docs/skylark/tutorial-creating-a-macro.md
+++ b/site/docs/skylark/tutorial-creating-a-macro.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Creating a Macro
+title: Creating a macro
 ---
 
-# Creating a Macro
+# Creating a macro
 
 Let's suppose you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/site/docs/skylark/tutorial-sharing-variables.md b/site/docs/skylark/tutorial-sharing-variables.md
index 2cc7724..4cfb364 100644
--- a/site/docs/skylark/tutorial-sharing-variables.md
+++ b/site/docs/skylark/tutorial-sharing-variables.md
@@ -1,9 +1,9 @@
 ---
 layout: documentation
-title: Sharing Variables
+title: Sharing variables
 ---
 
-# Sharing Variables
+# Sharing variables
 
 `BUILD` files are intended to be simple and declarative. They will typically
 consist of a series of a target declarations. As your code base and your `BUILD`
diff --git a/site/docs/skylark/windows_tips.md b/site/docs/skylark/windows_tips.md
index 77d6ab5..da8ae80 100644
--- a/site/docs/skylark/windows_tips.md
+++ b/site/docs/skylark/windows_tips.md
@@ -100,7 +100,7 @@
           return p
   ```
 
-## Environment Variables
+## Environment variables
 
 Problems:
 
diff --git a/site/docs/test-encyclopedia.html b/site/docs/test-encyclopedia.html
index 2536fa5..6fb0baa 100644
--- a/site/docs/test-encyclopedia.html
+++ b/site/docs/test-encyclopedia.html
@@ -1,6 +1,6 @@
 ---
 layout: documentation
-title: Test Encyclopedia
+title: Test encyclopedia
 ---
 <h1>Writing tests</h1>
 
@@ -41,7 +41,7 @@
 specification takes precedence.</p>
 
 
-<h2>Purpose of Tests</h2>
+<h2>Purpose of tests</h2>
 
 <p>The purpose of Bazel tests is to confirm some property of the source files
 checked into the repository.  (In this document, "source files" includes test data,
@@ -62,7 +62,7 @@
 <p>Currently, such behavior is not enforced. However, test runners reserve the
 right to add such enforcement in the future.</p>
 
-<h2>Role of the Build System</h2>
+<h2>Role of the build system</h2>
 
 <p>Test rules are analogous to binary rules in that each must yield an
 executable program.  For some languages, this is a stub program which combines
@@ -79,7 +79,7 @@
 image provided by the test runner, rather than hardcoded references to absolute
 locations in the source or output tree.</p>
 
-<h2>Role of the Test Runner</h2>
+<h2>Role of the test runner</h2>
 
 <p>From the point of view of the test runner, each test is a program which can
 be invoked with <code>execve()</code>.  There may be other ways to execute
@@ -193,7 +193,7 @@
 <p>When executing a test, the test runner must establish certain initial
 conditions.</p>
 
-<h2>Initial Conditions</h2>
+<h2>Initial conditions</h2>
 
 <p>The test runner must invoke each test with the path to the test
 executable in <code>argv[0]</code>.  This path must be relative and
@@ -310,7 +310,7 @@
 
 <p>The initial scheduling policy and priority are unspecified.</p>
 
-<h2>Role of the Host System</h2>
+<h2>Role of the host system</h2>
 
 <p>In addition to the aspects of user context under direct control of the
 test runner, the operating system on which tests execute must satisfy certain
diff --git a/site/docs/toolchains.md b/site/docs/toolchains.md
index 61d0de5..78e4cd1 100644
--- a/site/docs/toolchains.md
+++ b/site/docs/toolchains.md
@@ -356,7 +356,7 @@
 This will end up building `//bar_tools:barc_linux` but not
 `//barc_tools:barc_windows`.
 
-## Toolchain Resolution
+## Toolchain resolution
 
 **Note:** [Some Bazel rules](platforms-intro.html#status) do not yet support
 toolchain resolution.
diff --git a/site/docs/user-manual.html b/site/docs/user-manual.html
index db6fabe..fcc09f0 100644
--- a/site/docs/user-manual.html
+++ b/site/docs/user-manual.html
@@ -1,10 +1,10 @@
 ---
 layout: documentation
-title: User Manual
+title: User manual
 ---
-<h1>Commands and Options</h1>
+<h1>Commands and options</h1>
 
-<h2 id='target-patterns'>Target Syntax</h2>
+<h2 id='target-patterns'>Target syntax</h2>
 
 Some commands, like <code>build</code> or <code>test</code>, can operate
 on a list of targets. They use a syntax more flexible than labels, which is
diff --git a/site/docs/windows.md b/site/docs/windows.md
index 387132f..7696959 100644
--- a/site/docs/windows.md
+++ b/site/docs/windows.md
@@ -17,9 +17,9 @@
 label. [You can see the open issues here.](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Ateam-Windows)
 
 <a name="running-bazel-shells"></a>
-## Running Bazel: MSYS2 shell vs. Command Prompt vs. PowerShell
+## Running Bazel: MSYS2 shell vs. command prompt vs. PowerShell
 
-We recommend running Bazel from the Command Prompt (`cmd.exe`) or from
+We recommend running Bazel from the command prompt (`cmd.exe`) or from
 PowerShell.
 
 As of 2020-01-15, we **do not recommend** running Bazel from `bash` -- either