How I Approach WordPress Projects: From Planning to Launch

When a WordPress project goes wrong, the cause is rarely a plugin or a theme. More often, nobody agreed early on what the site had to do, who would look after it, and what “finished” meant. This article describes the process I follow to avoid that, from the first message to the handover after launch.

1. Start with the problem, not the theme

Before choosing a theme or a plugin, I want to understand the people who will use the site and the job it has to do. A short brief is enough to start, and the first reply is usually a list of questions rather than a quote.

Questions I ask in the brief

• Who will use the site, and what should they be able to do on it?
• Who will edit the content after launch, and how comfortable are they with WordPress?
• What has to connect to it: forms, a store, a CRM, a booking system, email?
• Is there a deadline, and what is driving it?
• What already exists that must keep working, such as URLs, content or integrations?

2. Agree on the scope in writing

Once the questions are answered, a short call can help, and then I send a written proposal with the scope, timeline and price. It lists what is included and, just as important, what is not. When something new comes up during the build, we agree on it before it is added, so the timeline stays honest. The services page describes what each type of project usually includes.

3. Plan the content structure before the layout

In WordPress, a lot of long-term pain comes from content that was built as a one-off layout. Early on, I decide what should be a page, what should be a post, and what deserves its own post type with custom fields. Editors then fill in clear fields instead of rebuilding a design every time they add something.

On this site, for example, projects and services are their own post types, with fields for the status, the stack and what is included. Each project page is built from those fields, so adding a new project does not need a new layout.

4. Build on a staging site

All work happens on a staging copy of the site, never on the live one. The staging site is kept out of search engines, and it is backed up before every significant change, so any step can be undone.

A quick database backup with WP-CLI

If the host provides WP-CLI, a database export is one command:

wp db export backup-$(date +%Y%m%d-%H%M).sql

Some hosts restrict this command. In that case, use the host’s own backup tool before you change anything.

Keep the staging site out of search results

WordPress has a setting for this under Settings → Reading (“Discourage search engines from indexing this site”). With WP-CLI it is one command:

wp option update blog_public 0

This setting only asks search engines not to index the site. For a stronger signal, the server can also send an X-Robots-Tag: noindex header. Both have to be undone at launch.

5. Use global styles instead of one-off styling

Colours, typography and spacing are set once in the theme’s global settings, for example the Kadence global palette and typography, and reused everywhere. Pages stay consistent, and a change to a colour or a heading size is made in one place instead of on every page.

6. Test like a visitor, not only like a developer

Before anything goes live, I go through the site the way a visitor would:

• At desktop, tablet and phone widths, and in both light and dark mode if the site has them.
• With the keyboard only, to check that every link, button and form field can be reached and that focus is visible.
• Forms with empty and invalid input, to check that the error messages are clear.
• Page speed and layout shifts on a normal connection.
• Every link in the menus, the footer and the main pages.

7. Launch with a checklist

• Take a final backup of the files and the database.
• Allow search engines to index the site.
• Add redirects for any URLs that changed.
• Send a test message through each form to make sure the email arrives.
• Confirm that HTTPS works on every page.
• Turn on analytics only if it is needed, and only with the consent it requires.

Moving from the staging address to the live one

If the site was built on a staging address, that address is stored throughout the database. WP-CLI can replace it, and a dry run shows what would change before anything is written:

wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables --dry-run

wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables

Unlike a plain SQL replace, wp search-replace also updates serialized data, which WordPress and many plugins use to store settings. Take the final backup before you run it.

8. Hand over so the site does not depend on me

A project is not finished when the site is live. It is finished when the people who run it can edit it with confidence. The handover includes short documentation of where each setting lives and how content is added, written so your team can edit the site and the next developer can understand it.

Final thoughts

None of these steps is complicated on its own. What makes the difference is doing them in this order: understand the problem, agree on the scope, structure the content, build safely, test like a visitor, launch carefully and hand over properly.

If you are planning a WordPress project, send me a short brief and I will reply with the questions that matter for your site. You can also see recent work or read about WordPress development.