A first website, planned properly / Rob Urban
Before the homepage,
do the homework.
You want a website. Good. Before you choose a theme, decide what a visitor needs to understand, what they should be able to do, and who will keep the whole thing useful after launch.
What should you plan
before building a website?
Start with the audience, the job the site must do, the content needed to do it, the required functions, the people responsible and the budget for both launch and upkeep. Those decisions give design and development something concrete to solve.
“We need a modern website” describes a preference. “People need to check whether we serve their area and request the right type of appointment” describes work the website can actually perform. The second statement helps you decide what belongs on the page.
I would rather begin with a rough explanation of the business than a polished list of features nobody has connected to a customer need. A carousel is easy to request. Explaining why someone should choose you takes more thought.
This guide is for planning that first useful version. If you are looking for help executing a WordPress project, my WordPress web design page explains that work in more detail.
Put the project into words
A brief someone
can build from.
Imagine a small furniture repair business preparing its first website. This is an invented example, not a client case study. The owner initially asks for a gallery, a booking calendar and an online store. A short planning conversation could produce a much more useful first scope.
- Who is arriving?
- Local owners of damaged furniture who need to know whether a repair is practical and whether the business handles that type of piece.
- What must they learn?
- Which repairs are offered, the area served, examples of relevant work, what affects an estimate and what information the team needs.
- What should they do?
- Send a repair inquiry with the details needed for an initial assessment. The page explains that an inquiry is not a confirmed appointment or final quote.
- What happens inside?
- A named person reviews the inquiry, requests missing details and explains the next step. The website promise matches the team’s actual capacity.
- What can wait?
- An online store has no first-release purpose if there are no products ready to sell. A booking calendar can wait if every job needs assessment before scheduling.
- What counts as progress?
- Suitable inquiries contain enough information to begin a useful conversation. The owner also records unsuitable requests and repeated questions that the pages should answer.
The point is not that small businesses should avoid features. It is that each feature should have a job. A simpler first release can be the right scope when the business process is still being clarified.
The material comes before the layout
Build a page map
around real questions.
A homepage, About page, service pages and contact route are common starting points. They are not a universal prescription. A portfolio, a shop and a membership organization need different information and different paths.
For each proposed page, write down its reader, their main question, the answer you can provide and the next useful destination. If two pages perform exactly the same job, explain why both need to exist before writing both.
A service page needs substance.
For our repair example, show the work accepted, relevant limitations, the assessment process and real photographs used with permission. Explain the factors that affect a quote without inventing a price you cannot honor.
A contact page needs expectations.
Say what to send, who will respond and what happens next. Only promise a response time the business can meet. Provide a practical alternative when someone cannot use the preferred contact method.
Assign the content work.
Someone must supply the facts, write or review the copy, select images, confirm permissions and approve the result. “We will add the content later” is how a project acquires a beautiful empty room.
Make a short inventory: material ready to use, material needing revision and material that does not exist yet. Give each missing item an owner and a due date. A team photograph that nobody has arranged is a schedule dependency, not a design problem.
For the writing itself, I go deeper into finding useful details in Your Company Is Probably More Interesting Than Your Website. This planning stage is where you make room to gather those details.
Give search a sensible place in the plan.
Use clear page titles, descriptive headings, useful internal links and language your readers recognize. Google’s SEO Starter Guide explains how these fundamentals help people and search engines understand a site. It also makes clear that following good practice does not guarantee a top ranking.
Decide which page answers each important question. Do not multiply near-identical pages because a spreadsheet contains several similar phrases. If you are replacing an existing site, inventory its current URLs and useful content before deciding what moves, stays or is retired.
Choose for the work ahead
The platform decision
includes Tuesday morning.
The site may look wonderful at launch. On Tuesday morning, somebody needs to change a service description, replace an image or correct an opening time. Include that person in the platform decision.
Instead of assuming one platform is best for every small business, test the tasks that matter. Ask the proposed provider to show how your team would edit a page, publish an article, manage a product if needed, and recover from an ordinary mistake.
- Content: Can the team maintain the kinds of pages and information you expect to publish?
- Transactions: If people buy, book or subscribe, what rules must the system handle?
- Connections: Which forms, payment services or business systems must exchange information, and who supports that connection?
- Access and exit: Who controls the domain and accounts, and what can you take with you if the arrangement ends?
- Ongoing work: Who handles updates, renewals, support and recovery?
Keep important accounts under appropriate business control, with named access for the people who need it. Record the account owner, renewal responsibility and recovery process without placing passwords in a shared project brief.
If the proposed site involves member permissions, complex workflows or a custom application, the planning question becomes larger. My website development and digital product strategy page covers that territory, including when specialized development help belongs in the project.
Budget for the complete assignment.
Separate initial strategy, content, design, implementation and migration work from recurring platform, hosting, licensing and support costs. Ask what is included in revisions, who supplies assets and what happens when the scope changes.
A price without those boundaries is difficult to compare. So is a launch date that assumes everyone will approve everything on the first attempt. Name the decision-maker and include time for content review and corrections.
Review what people will actually use
A homepage screenshot
is the beginning of QA.
Give reviewers tasks. Ask them to find a service, understand its limits, reach the right contact route and explain what happens next. Watch where the site makes them guess.
Check the important pages on phones, tablets and desktop screens, including longer headings, menus, forms, tables and the footer. A layout that narrows successfully can still have tiny controls, awkward reading order or essential information hidden behind an interaction.
Read the finished pages.
Confirm names, facts, service areas, contact details, image rights and offer conditions. Replace placeholders. Check that the page still makes sense to someone who has never attended your project meetings.
Use the interface.
Follow links, open menus, navigate by keyboard and look for a visible focus indicator. Check labels and error explanations. Review captions or alternatives where media carries important information.
Trace the important action.
In an agreed test environment or controlled test process, verify the form or checkout through to its destination. Seeing a success message is not enough if the inquiry never reaches the person responsible. Keep test records distinguishable from real customers.
Inspect the live release.
Confirm the intended pages load at the right addresses, public pages are available for indexing, old URLs are handled where needed, and the contact path still works after launch. Check the actual site rather than assuming a successful deployment proves everything.
The W3C WAI Easy Checks resource offers a starting point for accessibility review. WAI explicitly cautions that these basic checks are not a comprehensive assessment. Passing a short checklist should not be presented as accessibility certification.
Performance needs its own review too. Look for oversized images, delayed content, unstable layouts and slow interactions on the pages people actually use. Record the test conditions and what remains unverified. A fast-looking screenshot cannot tell you how a page behaves on a slower connection.
Launch is a change of responsibility
What should be handed over?
Before calling the project finished, make sure the business can operate what it now owns. Keep a usable record of the site accounts, domain renewal, hosting arrangement, licenses, approved content, key integrations and support contacts.
Ask for the instructions needed for routine changes, plus a clear route for problems that require technical help. Agree who checks updates, failed forms and expiring subscriptions. These tasks are easy to neglect when everyone assumes somebody else inherited them.
For a typical WordPress site, WordPress’s backup guidance explains that a complete recovery needs both files and the database. Establish what is backed up, how recently, where it is retained and how recovery is tested. A copy that nobody can restore is not much comfort during an outage.
Measure the job you gave the site.
Return to the original brief. Are suitable people finding the information they need? Do inquiries arrive with useful detail? Can the team keep content accurate? If there is a measurement system, define its events and check that it records the intended actions before trusting the dashboard.
Review real questions and failures after launch. In our repair example, repeated requests for an unsupported service may mean the wording is unclear. Repeated requests from outside the service area may mean the location information is too hard to find. Those observations give the next improvement a reason to exist.
Start with what you know
You can bring the idea.
It does not need to
arrive as a specification.
You may know the current site feels wrong, or that the business has outgrown the way it explains itself. You may be starting from nothing beyond a name and a clear sense of who you want to help.
You do not need to know exactly what needs solving before contacting me. Tell me what you are trying to make possible, what you already have and where you are getting stuck. We can work out which decisions need attention first.
Talk with me about the website you have in mindWritten by Rob Urban. The furniture repair example is illustrative. Technical references reviewed September 24, 2026.