diff --git a/docs/howto/static-files/deployment.txt b/docs/howto/static-files/deployment.txt
index 805e799eaac..6c116f816f9 100644
--- a/docs/howto/static-files/deployment.txt
+++ b/docs/howto/static-files/deployment.txt
@@ -117,7 +117,7 @@ Serving static files from a cloud service or CDN
 Another common tactic is to serve static files from a cloud storage provider
 like Amazon's S3 and/or a CDN (content delivery network). This lets you
 ignore the problems of serving static files and can often make for
-faster-loading webpages (especially when using a CDN).
+faster-loading Web pages (especially when using a CDN).
 
 When using these services, the basic workflow would look a bit like the above,
 except that instead of using ``rsync`` to transfer your static files to the
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 70e6005e8e5..531b1c872c2 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -305,7 +305,7 @@ Methods
         Mixing HTTP and HTTPS on the same site is discouraged, therefore
         :meth:`~HttpRequest.build_absolute_uri()` will always generate an
         absolute URI with the same scheme the current request has. If you need
-        to redirect users to HTTPS, it's best to let your webserver redirect
+        to redirect users to HTTPS, it's best to let your Web server redirect
         all HTTP traffic to HTTPS.
 
 .. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
diff --git a/docs/releases/1.3.6.txt b/docs/releases/1.3.6.txt
index 9ed92bd6c2e..ab2e86c6613 100644
--- a/docs/releases/1.3.6.txt
+++ b/docs/releases/1.3.6.txt
@@ -16,10 +16,10 @@ Host header poisoning
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
 header. Django's documentation has for some time contained notes advising users
-on how to configure webservers to ensure that only valid Host headers can reach
+on how to configure Web servers to ensure that only valid Host headers can reach
 the Django application. However, it has been reported to us that even with the
-recommended webserver configurations there are still techniques available for
-tricking many common webservers into supplying the application with an
+recommended Web server configurations there are still techniques available for
+tricking many common Web servers into supplying the application with an
 incorrect and possibly malicious Host header.
 
 For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
diff --git a/docs/releases/1.4.4.txt b/docs/releases/1.4.4.txt
index c15c0e14c37..57efe5de8a7 100644
--- a/docs/releases/1.4.4.txt
+++ b/docs/releases/1.4.4.txt
@@ -17,10 +17,10 @@ Host header poisoning
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
 header. Django's documentation has for some time contained notes advising users
-on how to configure webservers to ensure that only valid Host headers can reach
+on how to configure Web servers to ensure that only valid Host headers can reach
 the Django application. However, it has been reported to us that even with the
-recommended webserver configurations there are still techniques available for
-tricking many common webservers into supplying the application with an
+recommended Web server configurations there are still techniques available for
+tricking many common Web servers into supplying the application with an
 incorrect and possibly malicious Host header.
 
 For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist
index e4b6e3064b9..d9051969506 100644
--- a/docs/spelling_wordlist
+++ b/docs/spelling_wordlist
@@ -949,13 +949,7 @@ virtualenv
 virtualenvs
 virtualized
 Votizen
-webapps
-webkit
-WebKit
 Weblog
-webpages
-webserver
-webservers
 whatsnext
 whitelist
 whitelisted