01 / Before the build

Plan the pages around what customers need

Start the website brief with your main services or products, the people who buy them and the areas you serve. Then list the questions those customers need answered before they contact you or place an order.

Use that information to plan the pages. A service business may need separate pages for genuinely different services. A retailer may need product categories that match how customers browse. The structure should make sense to someone who has never heard of the business.

For example, an Edmonton renovation company might separate kitchen, bathroom and basement work because the projects involve different questions and processes. It does not need dozens of near-identical pages for minor wording variations.

Give each important page a clear job

Record the page’s purpose, the customer question it answers and the next step it supports. This helps the writer and developer work from the same brief. It also makes it easier to spot missing information before page layouts are approved.

If you are replacing a website, review the existing pages and their performance before deciding what to keep. Useful content and established URLs should be considered during planning, rather than rediscovered after launch.

02 / Navigation and URLs

Make important pages easy to reach

Navigation should help visitors find what the business offers without guessing which menu label to choose. Use familiar terms, group related pages and link to the main services or product categories from relevant parts of the website.

Google’s link guidance explains that links generally need an HTML anchor with a destination address to be crawlable. A developer should confirm that important navigation works as a link, rather than relying only on a script or an interaction that may be difficult to follow.

Choose readable, consistent URLs that describe the page. Keep the structure manageable as the website grows. Avoid changing addresses merely to make them look newer; a URL change creates additional work and needs a plan.

Test the structure with someone unfamiliar with the site. Ask them to find a service, confirm availability and start an enquiry. Their difficulty can reveal problems that the project team has learned to work around.

03 / Content and headings

Write useful information before polishing the page

A visually attractive template can still leave customers without an answer. Write the essential content early enough to influence the layout. Explain the service, who it suits, what happens next and any limits that affect the decision.

Use headings to organise the subject and paragraphs to explain it. The main heading should describe the page, with supporting headings arranged in a logical order. Avoid turning every short promotional phrase into a heading.

Each important page needs a descriptive title and a relevant meta description. These help communicate the page’s purpose, although Google may generate different title links or snippets. Do not repeat the same description across the entire website.

Use evidence the business can support

Add accurate specifications, relevant qualifications, approved project photographs and clear explanations of your process. Avoid invented customer stories, results or credentials. If an example is hypothetical, say so.

Google’s people-first content guidance is a useful review reference. The aim is to give the intended visitor enough information to make progress. A long page filled with repeated claims is not more helpful simply because it contains more words.

Images should also serve the page’s purpose. Provide meaningful alternative text when an image communicates information, and avoid using an image as the only place where essential service details appear.

04 / Technical access

Check that public pages can be accessed and indexed

A development website often needs protection while the work is unfinished. Password protection can restrict access to a private staging site. Indexing controls may also be used during development, but the team must know which settings need to change before the public launch.

A noindex instruction tells Google not to index a page. A robots.txt rule controls crawling; it is not a reliable way to keep a URL out of search results or protect private information. Google’s content control guidance explains the different uses of these settings.

For public pages intended for search, check the live website rather than assuming that the staging settings were removed. Confirm that important text and links are available and that pages return appropriate responses.

Check the main page types

Test a service page, a product or category page where relevant, a blog and the contact page. A template issue can affect many URLs at once. Google’s developer guidance provides a starting point for reviewing access and rendered content.

An XML sitemap can help search engines discover preferred public URLs. Canonical tags can indicate a preferred version where similar pages exist. Neither is a substitute for checking whether the right content is accessible, and neither guarantees indexing or rankings.

05 / Mobile use and performance

Build a website that works beyond the preview screen

Review the site on real phones and different screen sizes. Check whether visitors can read the text, open menus, compare information and complete forms without unnecessary effort. A desktop preview cannot confirm the whole experience.

Large media files, unnecessary scripts and heavy page features can affect loading and interaction. Ask the developer to consider performance while choosing templates and features, rather than leaving it to a final score check.

The current Core Web Vitals cover loading performance, responsiveness and visual stability through LCP, INP and CLS. Test results can help diagnose problems. A new site may not yet have enough real-user data for every page.

A high test score is not a ranking guarantee. Use the findings to improve the customer experience, and test the actual pages people will use rather than focusing only on the homepage.

06 / Contact and measurement

Test how an enquiry reaches your team

Make the next step easy to understand. A service page might invite a quote request, while a product page may support an order or a question about compatibility. The action should fit the page and the customer’s stage of the decision.

Keep forms relevant to the task. Ask for the information the team needs to respond, label fields clearly and explain errors in a way the visitor can act on. Confirm that the submission arrives in the right inbox or customer system.

Agree on what will be recorded

Plan analytics and enquiry measurement before launch. Decide which actions matter, who is responsible for the setup and how the recordings will be checked. The implementation should account for applicable consent choices and the organisation’s privacy requirements.

Record a successful test submission and check what appears in the reporting. Distinguish a phone-link click from a connected call and a submitted form from a suitable enquiry. Those differences matter when the business later decides whether its marketing is working.

Search Console can help the team review search visibility and indexing after launch. The business should retain appropriate account access rather than depend on one person’s personal login.

07 / Launch and migration

Treat launch as a checked release

Assign ownership for launch checks and record who will handle problems. Review the live domain, secure connection, page links, forms, indexing instructions and contact information after the release.

If existing URLs are changing, prepare a map from each important old address to the most relevant new destination. Where there is a suitable replacement, use an appropriate permanent redirect. Avoid sending every removed URL to the homepage.

Google’s site migration guidance also covers updating internal links and other signals to the new addresses. Include important images and downloads in the migration plan, not just the visible pages.

Search visibility can fluctuate during a move. No migration plan can promise that every ranking will remain unchanged. Careful preparation gives the team a clearer way to preserve useful information and respond to issues.

08 / Ongoing ownership

Choose a website your team can maintain

Before signing off, confirm who controls the domain, hosting, content system and reporting accounts. Agree on access, backups, updates and the process for fixing a problem. The business should know whom to contact if a form stops working or an important page becomes unavailable.

Ask the developer to show how everyday content changes are made. Your team should be able to update titles, descriptions, headings, images and service details without accidentally disrupting the page structure. More technical changes may still need specialist support.

An SEO-friendly foundation does not mean that the website is finished forever. Offers change, information becomes outdated and new content needs review. Plan maintenance and content responsibility alongside the original build.

When discussing website development, ask which search-related checks are included and what happens after launch. If the site already exists, an SEO audit can help identify gaps before a redesign or further investment.

09 / Common questions

Frequently asked questions