WordPress Build: Building a Site the Way That Survives the First Year

A WordPress build that lasts is done in a specific order: choose managed hosting with backups and a staging copy first, install WordPress on it, pick one well-maintained theme and put your changes in a child theme, add the five plugins the site actually needs rather than the thirty a tutorial suggests, build the pages on staging, then push to live and point the domain. The order matters because each step constrains the next: hosting decides whether you get staging and backups, the theme decides how much of your work is disposable, and the plugin count decides how many updates can break the site in year two. Most beginner guides start with the theme and end with the launch, which is exactly backwards.

The keyword covers both meanings of build, the site and the process, and the process is the part that decides whether the site is still working in twelve months. This is the sequence for a business site, a blog or a portfolio, written for the person who will be responsible for the site after the launch, which is usually the same person who built it.

Table of contents

• Step one: hosting decides everything after it
• Step two: install, then do the five settings before anything else
• Step three: one theme, and a child theme from the first minute
• Step four: five plugins, not thirty
• Step five: build on staging, then push
• Step six: launch, and the first year
• How this fits the rest of the stack
• FAQ

Step one: hosting decides everything after it

WordPress is a PHP application with a MySQL database and a directory of uploads, and it needs somewhere to run all three. The hosting choice is first because it decides four things you cannot add later without moving the site.

• Backups you did not have to configure. A site is its database plus its uploads directory, and a plugin that backs them up into the same account is not a backup. Managed WordPress hosting takes backups at the platform level, outside the site.
• A staging copy. Somewhere to test a theme update or a new plugin before it touches the live site. Without it, every update is a live experiment.
• A way to see and edit files and the database without SFTP and phpMyAdmin. When a plugin update produces a white screen, the fix is renaming one directory, and doing that from a dashboard file manager takes a minute; doing it over SFTP after finding the credentials takes an hour.
• A plan that can grow. A site that starts on a small plan and gets traffic should move to a larger one, not to a different host.

On RunxBuild, managed WordPress starts at $3 a month on the Starter plan, and the dashboard includes a file manager and a database browser, which are the two tools above. Whatever host you pick, confirm those four items exist before installing anything.

Step two: install, then do the five settings before anything else

Most managed hosts install WordPress in one click. Immediately after, before a theme, five settings that are painful to change later:

1. Permalinks to Post name, under Settings, Permalinks. Changing this after content exists means redirects for every URL.
2. Site address and WordPress address to the final domain with HTTPS, or leave both on the temporary hostname until launch and use a search-and-replace tool at cutover. Never mix the two.
3. Timezone, date format and language under General. Scheduled posts and reports depend on it.
4. Discourage search engines ticked under Reading while the site is being built, and a calendar reminder to untick it at launch.
5. Delete the default content: the sample post, the sample page, the default plugins you will not use. Every unused plugin is an update you will have to apply.

Step three: one theme, and a child theme from the first minute

Choose one theme with a large user base, recent updates, and a demo that looks like the site you want without customisation. Block themes are the current direction and let you edit the whole site in the editor; classic themes with a page builder are the established alternative. Either is fine. Switching later is a rebuild, so pick once.

Then create a child theme before changing anything. A child theme is a folder with a stylesheet and a functions file that inherits everything from the parent, and it is where your CSS and code changes live. When the parent theme updates, your changes survive. When you edit the parent theme directly, the next update deletes your work, and that update will arrive.

/* wp-content/themes/mysite-child/style.css */
/*
Theme Name: My Site Child
Template: parent-theme-folder-name
*/

<?php
// wp-content/themes/mysite-child/functions.php
add_action('wp_enqueue_scripts', function () {
    wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
});

Two files, and the site is now safe to customise. Upload the folder through the file manager, activate the child, and forget the parent exists.

Step four: five plugins, not thirty

Every plugin is code from someone else running on your site, updated on their schedule, and capable of breaking the site or opening it up. The right number is the smallest that does the job, and for most sites it is roughly five.

• An SEO plugin for titles, descriptions and the sitemap.
• A form plugin for the contact page.
• A caching or performance plugin, unless the host handles caching at the platform level, in which case skip it.
• A security hardening plugin for login attempt limits and file change alerts, or the host’s equivalent.
• Whatever the one thing the site is for needs: the e-commerce plugin, the booking plugin, the membership plugin. One.

What is not on the list: a backup plugin, if the host backs up; a page builder, if the theme is a block theme; sliders, social feeds, analytics plugins that a script tag replaces, and anything installed to try once and never removed. Before adding a plugin, check when it was last updated and how many sites use it. Before keeping one, ask what breaks if it is deleted.

Step five: build on staging, then push

Pages, navigation, the home page layout, the images sized correctly before upload: all of it on the staging copy, with the live site untouched. When staging looks right, push it to live in one operation. From then on, the loop for every change bigger than a typo is the same: make it on staging, check it, push.

Updates follow the same loop. WordPress core, the theme and the plugins all release updates, and each one is a chance for something to break. Apply them on staging first. If staging survives, apply to live. If it does not, you have found the problem without an outage, and the fix is usually waiting a week for the plugin author to release a patch.

Step six: launch, and the first year

Launch is pointing the domain at the host, letting the certificate issue, untucking the search engine setting, and running a search-and-replace if the site was built on a temporary hostname. Then the maintenance rhythm that keeps it alive:

• Weekly: apply updates on staging, then live. Ten minutes.
• Monthly: open the file manager and the database browser, look at what has grown. Uploads and post revisions are the usual culprits. Confirm a backup exists and, once a quarter, restore one to staging to prove it works.
• On every white screen: rename the plugin directory that was last updated, using the file manager. The site comes back, and you have found the culprit.

A site built in this order has a child theme that survives updates, a plugin list short enough to audit, a staging copy for every change, and backups outside the site. That is the whole difference between a WordPress build that is still working in a year and one that is a support ticket.

How this fits the rest of the stack

The tooling in step one is the part that most guides assume you will figure out later. On managed WordPress on RunxBuild, the file manager and the database browser are in the dashboard, backups are platform-level, and the plan ladder runs from $3 a month upward as the site grows. The RunxBuild hosting calculator shows what the WordPress plan and the bandwidth come to together, which is the honest number to compare against a build quote.

Useful related references:

• WordPress 6.8.2: What a Maintenance Release Is and How to Handle It
• Squarespace vs WordPress: The Question Behind the Question
• WordPress Maintenance Services: What You Are Actually Paying For
• Managed WordPress on RunxBuild

FAQ

What is the correct order to build a WordPress site?

Hosting first, then install and set permalinks and the site address, then one theme with a child theme, then a short plugin list, then build the pages on a staging copy, then push to live and point the domain. Each step constrains the next, and hosting decides whether you get staging, backups and file access at all.

Do I need a child theme?

Yes, if you plan to change any CSS or code. A child theme inherits the parent and holds your changes in two small files, so theme updates do not overwrite them. Editing the parent directly means the next update deletes your work.

How many plugins should a WordPress site have?

As few as do the job, typically around five: SEO, a form, caching if the host does not provide it, security hardening, and the one plugin the site’s purpose requires. Every plugin is an update that can break the site, so audit the list and remove anything you cannot justify.

What is a staging site and do I need one?

A copy of the site where you test updates and changes before applying them to the live site. Yes, you need one. Without it every theme, plugin and core update is a live experiment. Most managed WordPress hosts provide staging as a one-click copy.

What should I do when a WordPress site shows a white screen after an update?

Rename the directory of the plugin or theme that was just updated, which deactivates it. The site comes back and you have identified the cause. Doing this through a dashboard file manager takes a minute; over SFTP it takes considerably longer, which is why file access matters in the hosting choice.