Workflow for WordPress Site Development

When I first started developing sites on WordPress, my strategy for developing a site prior to launching it was similar to many other developers:

  1. Install WordPress on a subdirectory of my own domain, like:
  2. Get everything working and pretty and get client approval to launch
  3. Export mySQL database, search and replace paths, download/upload sitefiles, curse weird incompatible settings at client’s hosting provider, etc

Over time, and after learning about how to install WordPress in its own subdirectory while pointing the actual site at the root domain, I developed a different workflow:

  1. Install WordPress on a subdirectory of client’s domain, like: * – and thereby find out and resolve immediately if there are any hosting issues (permissions, mySQL access, poor performance, etc)
  2. Get everything working  and pretty and get client approval to launch
  3. Follow the instructions to use a subdirectory install and point the site to the root:

If the site is a new site, rather than a redesign, you can of course simply use a Maintenance Mode plugin and just develop the site at the root anyway, and give the client a login to preview it during development. I preferred to follow the flow above and put a static index.html page at the root, with a couple paragraphs of SEO-rich text copy about the new business. That way, when sending a client a link to preview their site I could just point them to the subdirectory: . That seemed to work out a lot better than directing them to login to their dashboard and then view their site  in another tab. Especially since often the client would want to forward the link to an associate or spouse or friend, and the requirement to be logged in seemed to generate a lot of unhappy “something is broken, no one else can see the site” emails.

Then, once the site was approved for launch I could simply remove the index.html file at the root, and point the WP install to the root. All done in a couple minutes instead of potentially, hours. Meanwhile, having the SEO-rich placeholder page at the root for a few weeks during development means Google will have already indexed the site by the time it’s launched.

* I use a keyword appropriate to the client’s business as the subdirectory name rather than something generic like dev or test or newsite, since all the paths in the sourcecode of the pages will include this word. Image paths for example would appear like this:

Hard to say if there’s any real SEO advantage in doing so, but I figure it can’t hurt, and I prefer how it looks/reads versus the more generic alternatives.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s