Step back one edit

The edit of this line goes a little far, so let's walk the
technical statement back slightly.

doc/administration/pages/source.md

@@ -10,8 +10,8 @@ NOTE:
 Before attempting to enable GitLab Pages, first make sure you have
 [installed GitLab](../../install/installation.md) successfully.
 
-This is the documentation for configuring a GitLab Pages when you have installed
-GitLab from source and not using the Omnibus packages.
+This document explains how to configure GitLab Pages when you have installed
+GitLab from source and not the Omnibus packages.
 
 You are encouraged to read the [Omnibus documentation](index.md) as it provides
 invaluable information about the configuration of GitLab Pages.
@@ -22,10 +22,9 @@ Pages to the latest supported version.
 
 ## Overview
 
-GitLab Pages makes use of the [GitLab Pages daemon](https://gitlab.com/gitlab-org/gitlab-pages), a simple HTTP server
-written in Go that can listen on an external IP address and provide support for
-custom domains and custom certificates. It supports dynamic certificates through
-SNI and exposes pages using HTTP2 by default.
+GitLab Pages makes use of the [GitLab Pages daemon](https://gitlab.com/gitlab-org/gitlab-pages), a lightweight HTTP server that listens on an external IP address and provides support for
+custom domains and certificates. It supports dynamic certificates through
+`SNI` and exposes pages using HTTP2 by default.
 You are encouraged to read its [README](https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md)
 to fully understand how it works.
 
@@ -57,7 +56,7 @@ Before proceeding with the Pages configuration, make sure that:
   assume that to be `example.io`.
 - You have configured a **wildcard DNS record** for that domain.
 - You have installed the `zip` and `unzip` packages in the same server that
-  GitLab is installed since they are needed to compress and decompress the
+  GitLab is installed because they are needed to compress and decompress the
   Pages artifacts.
 - Optional. You have a **wildcard certificate** for the Pages domain if you
   decide to serve Pages (`*.example.io`) under HTTPS.
@@ -86,7 +85,7 @@ see the [security section](#security).
 Depending on your needs, you can set up GitLab Pages in 4 different ways.
 The following options are listed from the easiest setup to the most
 advanced one. The absolute minimum requirement is to set up the wildcard DNS
-since that is needed in all configurations.
+because that is needed in all configurations.
 
 ### Wildcard domains
 
@@ -96,7 +95,7 @@ since that is needed in all configurations.
 
 URL scheme: `http://<namespace>.example.io/<project_slug>`
 
-This is the minimum setup that you can use Pages with. It is the base for all
+This setup is the minimum you can use Pages with. It is the base for all
 other setups as described below. NGINX proxies all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
@@ -150,8 +149,8 @@ The Pages daemon doesn't listen to the outside world.
 
    You may use an `http` address, when running GitLab Pages and GitLab on the
    same host. If you use `https` and use a self-signed certificate, be sure to
-   make your custom CA available to GitLab Pages, for example by setting the
-   `SSL_CERT_DIR` environment variable.
+   make your custom CA available to GitLab Pages. For example, you can do this
+   by setting the `SSL_CERT_DIR` environment variable.
 
 1. Add the secret API key:
 
@@ -264,8 +263,8 @@ that without TLS certificates.
 
 URL scheme: `http://<namespace>.example.io/<project_slug>` and `http://custom-domain.com`
 
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
+In that case, the pages daemon is running. NGINX still proxies requests to
+the daemon, but the daemon is also able to receive requests from the outside
 world. Custom domains are supported, but no TLS.
 
 1. Install the Pages daemon:
@@ -297,9 +296,9 @@ world. Custom domains are supported, but no TLS.
    ```
 
 1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
-   order to enable the pages daemon. In `gitlab_pages_options` the
-   `-pages-domain` and `-listen-http` must match the `host` and `external_http`
-   settings that you set above respectively:
+   order to enable the pages daemon. In `gitlab_pages_options`, the
+   `-pages-domain` must match the `host` setting that you set above and
+   `-listen-http` must match the `external_http` setting:
 
    ```ini
    gitlab_pages_enabled=true
@@ -329,8 +328,8 @@ world. Custom domains are supported, but no TLS.
 
 URL scheme: `https://<namespace>.example.io/<project_slug>` and `https://custom-domain.com`
 
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
+In that case, the pages daemon is running. NGINX still proxies requests to
+the daemon, but the daemon is also able to receive requests from the outside
 world. Custom domains and TLS are supported.
 
 1. Install the Pages daemon:
@@ -416,8 +415,8 @@ server_name ~^.*\.pages\.example\.io$;
 
 ## Access control
 
-GitLab Pages access control can be configured per-project, and allows access to a Pages
-site to be controlled based on a user's membership to that project.
+GitLab Pages access control can be configured per project. Access to a Pages
+site can be controlled based on a user's membership to that project.
 
 Access control works by registering the Pages daemon as an OAuth application
 with GitLab. Whenever a request to access a private Pages site is made by an