Session 1: Setup & Dashboard

This confusion costs beginners real money, so it comes first. WordPress.org is the free, self-hosted software: you download it, put it on hosting you pay for, and you own everything — the files, the database, the ability to install any theme or plugin. WordPress.com is a hosted service run by a company, where you rent space and accept their limits.

For the work this course prepares you for — building business sites for clients — you want WordPress.org on your own hosting. It is the version clients mean when they say I want a WordPress site, the version agencies use, and the only one where you can install the e-commerce, form and SEO plugins a business actually needs. WordPress.com's paid tiers can do some of this, but you are renting rather than owning, and moving away later is awkward.

The distinction also determines who is responsible. On your own hosting, you are responsible for updates, backups and security — which is exactly what the final session of this course teaches, and exactly what clients pay for. On a hosted service, they handle it and limit you. Neither is wrong; they are different products, and knowing which one you are on prevents every downstream confusion.

Hosting is where a beginner site goes to die, and not from anything visible. What matters, in rough order: reliability — a site that is down when a client's customer visits is a lost contract, so uptime history and honest reviews matter more than advertised features; PHP version — WordPress needs a current supported version, and cheap hosts sometimes leave you on an old one; SSL included, because HTTPS is not optional and paying extra for it is a warning sign; and real backups, not a checkbox nobody has tested.

Then the things specific to building for Nigerian businesses. Support responsiveness matters more than support availability — a host who answers in twenty minutes at 9pm is worth more than one with a 48-hour ticket queue. Server location affects speed for your visitors: a European server is usually a reasonable compromise for Lagos traffic, while a US server adds latency to every request. And payment — many international hosts charge in dollars, so know the exchange exposure before you quote a client an annual figure.

The practical advice is to start cheap and small. A shared plan is entirely adequate for a small business site, and the differences between mid-priced hosts are much smaller than the differences between a good host and a bad one. What you should not do is choose purely on price, because the cost of migrating a live client site after discovering the host is unreliable is far greater than the annual saving.

Almost every host offers a one-click installer, and you should use it — it creates the database, writes the configuration file and runs the setup in a minute. Knowing it exists is the point; there is no professional virtue in doing it manually on a client project.

It is still worth understanding what the installer did, because you will meet it again when something breaks. WordPress needs three things: the files on the server, a database to store content and settings, and a configuration file that tells the files where the database is. Every catastrophic WordPress failure is a problem with one of those three, and knowing which makes debugging possible rather than guesswork.

Then the setup itself, where two decisions matter. Use a strong administrator password, and do not name the administrator account admin, because admin is the first username every automated attack tries — this is not paranoia, it is the single most common way WordPress sites are compromised. And note your database credentials somewhere safe, because recovering them later is annoying at best.

The dashboard is the left-hand menu, and learning it is mostly learning where things are. Posts is blog content — dated, categorised, shown in reverse chronological order. Media is every file you have uploaded. Pages is your permanent content — Home, About, Contact. Comments is moderation. Appearance holds themes, customisation and menus. Plugins is installed functionality. Users is who can log in. Settings is configuration.

The distinction that confuses every beginner is Posts versus Pages, and it is worth fixing now because it decides how the whole site is organised. Pages are timeless and hierarchical — About does not expire, and Contact can have a child page. Posts are dated and grouped into categories — an article about a project you finished last month is a post. Getting this wrong means a client's news section that cannot be ordered, or a menu of blog entries that should have been pages.

Then the thing nobody tells you: the dashboard you see depends on your role. An administrator sees everything; an editor sees content but not plugins or settings; an author sees less still. On a client site you will create a lower-privilege user for them, and they will not see the things you can break — which is deliberate and is part of a responsible handover.

Most settings can be left alone, and five cannot. Permalinks — under Settings, change the structure to Post name, because the default includes the date and produces long, ugly, unshareable URLs; changing this later breaks every existing link, so do it before you have content. Timezone — set it to Lagos, or scheduled posts and dated content will be wrong by hours.

Site title and tagline appear in browser tabs and search results and are trivially forgotten. Discussion settings decide whether comments are open, and on a business site you almost certainly want them off or moderated, because unmoderated comments on a small business site become spam within days. And the fifth is the one that ruins launches: Search engine visibility.

That checkbox — Discourage search engines from indexing this site — is meant to be ticked while you build and unticked before you go live. People tick it during development, launch, and then wonder for months why nobody can find the site. It is a single checkbox, it is easy to forget, and it is the most expensive oversight in this entire course. Check it at launch, every time, and put it on your launch checklist.