diff --git a/admin_doc/source/new_server_feature.rst b/admin_doc/source/new_server_feature.rst
index 1ecb7aa3ad5c58133cbc4ea24aaadd5330ec432e..445837f93189558312535379c7be90936bcc4706 100644
--- a/admin_doc/source/new_server_feature.rst
+++ b/admin_doc/source/new_server_feature.rst
@@ -30,7 +30,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
     WSGI script file, since the daemon monitors this file for any changes::
 
         cd /home/gracedb/wsgi
-        touch wsgi.py
+        touch django.wsgi
 
 #.  Iterate until the code is in a state that you like. If the process is 
     involved, you may want to make several commits along the way:: 
@@ -46,7 +46,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
         export TEST_SERVICE='https://gracedb-test.ligo.org/api/'
         python test.py
 
-#.  If everythingg looks good, go back to gracedb-test, merge our branch into
+#.  If everything looks good, go back to gracedb-test, merge our branch into
     master, and push it::
 
         cd /home/gracedb/gracedb
@@ -64,7 +64,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
 
 #.  As with the test machine, you'll need to touch the WSGI script as well::
 
-        touch gracedb/wsgi/wsgi.py
+        touch gracedb/wsgi/django.wsgi
 
 And now your new feature or bugfix should be live on the production machine.
 The scenario I've outlined above is more-or-less the simplest way things can