×
Guides Instructions
07546 681 556
info@webdesigner.london

How a Professional Web Designer Plans a Site Step by Step

Planning a website is a business exercise first and a visual exercise second. Looks count, but they follow purpose and measurement. Good planning reduces risk, controls costs, and lays foundations for search visibility, speed, and conversion. It also keeps the project honest about what matters and what does not.

Professional Web Design Services In London Showing Clean Structure Responsive Build And Seo Optimised Interface

At a high level, the journey is straightforward. Set goals. Understand users and their tasks. Map the structure. Plan the content. Bake in SEO from day one. Make the right technical choices, including hosting and integrations. Prioritise performance and accessibility. Define a build workflow with version control, staging, and repeatable deployments. Run QA on real devices and in real scenarios. Launch in a controlled way. Maintain, monitor, and iterate. The specifics will vary by business, and that is fine – the aim is clear, testable decisions over trends.

A website project starts with the business case, not the colour palette. The aim is a site that supports real goals and can be measured. Good planning lowers risk, keeps costs under control, and sets up search visibility, speed, and conversion from the start.

Here is the path I use on client builds: set goals, understand users and their tasks, map the structure, plan the content, design the SEO foundations early, choose hosting and integrations with care, prioritise performance and accessibility, define a build workflow with version control, staging, and repeatable deployments, run QA on real devices in real scenarios, launch in a controlled way, then maintain, monitor, and iterate. The specifics will differ by business and sector – that is expected. What matters is making clear, testable decisions rather than chasing trends.

1. Clarify goals, constraints, and success

Turn business objectives into measurable outcomes before any design happens. If this step is fuzzy, everything after it drifts.

Audiences: small business owners, service companies, professionals, and founders in the UK and abroad. Value proposition: fast, well structured, SEO ready WordPress sites that generate qualified enquiries and are straightforward to maintain.

Primary goals and KPIs

Targets should be realistic and tied to baseline data. If there is no baseline, we set one in the first weeks after launch and adjust.

Non-goals and early trade-offs

Must-haves vs nice-to-haves

Sort features into two buckets. Be strict. It lowers risk and keeps the team honest.

Constraints to acknowledge

A quick note: preferences are fine, but they sit behind objectives. If a choice hurts speed, clarity, or conversion, we drop it. Write these decisions on a single page, circulate it, and refer back during design and build.

2. Understand users and conversion paths

Before visuals, we map who the site serves, what they need to do, and how they become a lead. This keeps design honest and prevents noise.

User segments and jobs to be done

We design for jobs to be done, not demographics. Role and intent guide the content and the calls to action.

Primary and secondary journeys mapped to conversions

Each journey ends on a simple decision screen. One main action, a supportive alternative, and no distractions.

Top tasks to prioritise in navigation and layout

If a task helps users decide, we surface it. If it adds noise, we move it down or drop it.

Conversion events defined and trackable

We implement GA4 events with clear names, consent-aware tags, and CRM integration. Clean thank you pages help with validation and reporting.

Offline context that affects the journey

What we avoid

Clarity wins. When in doubt, make the next step obvious and measurable.

3. Information architecture and navigation

Keep the structure simple, scalable, and easy to crawl. Humans should find the next step in one or two clicks. Search engines should see one clear home for each topic.

Draft sitemap with parent-child logic

Two levels max for core pages. Deeper content lives via filters, tags, or internal links, not nested menus.

Notes:

Navigation patterns – desktop and mobile

Navigation mirrors top tasks. Labels are plain English. No cleverness.

Breadcrumbs plan

Internal linking rules for priority pages

If a page does not receive any internal links, it probably should not be published. Or it belongs as a file download rather than a page.

Canonical and pagination strategy

Simple rule: fewer, stronger URLs beat many weak ones. If in doubt, fold content up and point to the best page.

4. Content model and page types

Design the content before visuals. It prevents messy builds, rework, and bloated pages. We plan page types, fields, and patterns first, then layer the design on top.

Page templates and key components

Lean set, clear purpose, consistent structure.

Custom post types and taxonomies

Services stay as Pages to keep URLs clean and breadcrumbs simple. We add CPTs only where it helps authors and listings.

Testimonials as a CPT only if there are many and you need rotation and filtering. Otherwise use a reusable testimonials block in context. Simpler is better.

Reusable blocks and patterns

Lock patterns where layout must not drift. Leave text and links editable. If a block makes authors nervous, it will gather dust.

Structured fields for key content

Implement with block templates and minimal meta fields. Use pattern placeholders to collect these items in a predictable order so archives and related blocks can rely on them.

Content governance and ownership

Avoid unstructured freeform pages and content locked inside decorative blocks. Keep the editor simple. A small set of clear patterns beats a drawer of one-offs.

5. SEO research and entity mapping

We plan for search before design. Topics first. Clear mapping. Clean on-page structure. It feels slower at the start. It saves months later.

Topics and intent clusters, not just keywords

Search intent is the reason behind a query. Someone wants to hire, compare, learn, or find a brand page. We group queries by that intent and plan clusters around them.

For a web design service in London, core clusters often include hiring a designer, WordPress performance, process and timelines, pricing factors, and proof. Each gets one strong page, then supporting posts where needed.

Entity relationships and supporting content

An entity is a clearly defined thing or concept. Think people, places, services, platforms, and outcomes. Search engines map how these connect. We make those connections obvious.

We reflect these entities in headings, internal links, and supporting articles. Short explainers, FAQs, comparisons, and checklists work well. Keep names consistent across the site.

Keyword-to-page mapping by template

One main topic per URL. No duplicates. We map each target phrase to a page type so the site stays tidy.

I keep a simple sheet for this. Nothing fancy. Just URL, primary topic, intent, template, internal links in and out, and status.

Title, meta, headings, and internal link rules

Meta title and meta description are the bits shown in search results. They should match the page and give a reason to click.

Schema markup plan for key types

Schema markup is extra code that labels the type of page. It helps search engines understand context and sometimes unlocks rich results like FAQs. We add it where it makes sense.

We validate markup during staging. If a type does not fit, we skip it. Bad markup hurts trust.

What we avoid

Simple workflow

This makes search part of the site plan, not an afterthought. It is calmer to run and easier to grow.

6. Performance budget and media plan We set speed targets before design starts. That keeps choices grounded and avoids surprises late on. Core Web Vitals targets and how we test Core Web Vitals are Google’s way of measuring how fast and stable a page feels. In plain terms – how quickly the main content appears, how steady the layout is, and how fast the page reacts when you tap or click. Largest Contentful Paint (main content visible) – target under 2.5 seconds for real users. We aim faster where possible. Interaction to Next Paint (response to a tap or click) – target under 200 ms. Cumulative Layout Shift (visual jumps) – target under 0.1. How we test it: During build – Lighthouse and WebPageTest on staging. We test key templates, not just the homepage. We emulate a mid-range phone on a normal 4G connection. It is closer to real life than a fast Mac on fibre. After launch – Google Search Console and the Chrome User Experience Report to see real user data. Quarterly checks – fix regressions before they stack up. Images – formats, sizes, and responsive rules Use modern formats first – WebP and AVIF where supported. Keep JPEG or PNG as a safe fallback when needed. Right-size every asset. We export to the largest size it will actually display, then let WordPress generate smaller versions for different screens. Responsive by default. We output srcset so browsers pick the best size automatically. No single giant image for all devices. Lazy load all below-the-fold images. Do not lazy load the main hero image. We mark it as high priority so it appears fast. Keep transparent graphics as SVG when possible. They are crisp at any size and usually lighter. Video – hosting and delivery Host marketing videos on a specialist platform like YouTube or Vimeo. We use privacy-enhanced, lightweight embeds so the page does not load their full player until needed. Self-host only short, muted loops and only when they add real value. We provide a poster image so the first frame is instant. No autoplay with sound. It annoys users and burns bandwidth. Controls visible, captions available. Defer loading videos below the fold. They should not block the main content. Fonts – strategy and fallbacks Prefer system fonts when brand allows. They are fastest and look clean. If brand fonts are required – we host them locally, use modern WOFF2 files, and limit to the few weights actually used. Preload the primary text font only, then use font-display: swap so text is readable immediately with a safe fallback. Define a clear fallback stack. If the custom font fails, the page still looks good. Avoid icon fonts. Use inline SVG icons – they are lighter and sharper. Third-party scripts – policy and review Every external script has a cost. We keep a simple policy so they do not slow the site or create risk. Purpose and owner required. No script goes live without a named reason and a person responsible. Load by need. Only on the pages that require it. Marketing tags behind consent where applicable. Defer or async so they do not block the main page from loading. Nothing in the critical path unless essential for content. Quarterly review. Remove unused pixels, A/B tools after tests end, and old chat widgets. One controller. A tag manager is fine if kept tidy. We test impact before and after adding any script. What we avoid by default Heavy page builders and unused libraries. We build with a lean WordPress stack so the site stays fast. Autoplay background videos with sound. Blocking scripts in the critical path. Icon fonts when SVGs will do. Set the budget, stick to it, and the design follows. It keeps pages quick, clean, and easier to maintain long term.

7. Technical choices for WordPress We choose a lean, maintainable stack that suits the project and the team. It keeps the site fast, secure, and easy to run without surprises. Theme approach – set early We decide the theme approach before design starts. That avoids rework later. A block theme uses the WordPress site editor and blocks for most of the layout. It is flexible and future facing if your team is happy editing with blocks. A hybrid theme mixes classic templates with blocks where it makes sense. It suits complex sites, legacy needs, or stricter layouts that should not be edited by mistake. We recommend a block theme when day to day updates will be done in house and you want visual control. We choose hybrid when stability and guardrails matter more. There is a clear path to add more blocks over time, not all at once. Plugins – few, supported, purposeful Plugins add features. Each one also adds risk and weight. We keep the list short. One plugin per job. No overlaps. For example, one SEO plugin, one forms plugin. Pick active, well supported plugins with a track record of updates. Favour native WordPress features before adding a plugin. Remove what is not used. Fewer moving parts means fewer issues. When we need something custom, we build it as a small, documented plugin and keep it in version control. Version control is a safe history of code changes so we can track edits and roll back if needed. Editor experience – patterns and permissions Your team should be able to update content without breaking layouts. We shape the editor around that goal. Block patterns for repeatable sections. Think ready made service blocks, FAQs, pricing rows. Lock the parts that should not move. Keep freedom where it helps. Roles and permissions set by task. Editors edit. Admins administer. No shared admin accounts. Clear names for media, patterns, and templates so people find the right thing fast. Short guides inside the dashboard. A few notes save a lot of support later. Hosting, CDN, and caching Good hosting is the foundation. A Content Delivery Network, or CDN, serves images and files from servers closer to your visitors. Caching stores ready made pages so they load quickly. Managed WordPress hosting with solid performance, staging, SSL, and backups. Use a CDN for static assets and large media. Faster worldwide and lighter on the server. Server level page caching first. Add a caching plugin only when needed. Do not stack multiple caches. Object caching where the host supports it. It helps logged in areas and searches. Set clear purge rules so updates appear quickly without wiping all caches. Monitoring and alerts. Fix small hiccups before they become outages. If you already have a host, we assess it honestly. Weak hosting costs more in lost time than the price difference suggests. Versions and updates We run on a currently supported PHP version and the current stable WordPress release. Old software is a security and speed risk. Minor security updates auto apply. Major updates are tested on staging, then scheduled for live. Plugins and themes reviewed and updated on a regular cycle. Backups and a simple rollback plan before any change. Documented change log so everyone knows what changed and why. What we avoid Plugin bloat and overlapping features. Custom code without version control. Shared admin accounts. Each person gets their own login with suitable access. Outdated PHP or weak hosting. Set these choices early and keep them tidy. The site stays quick, secure, and calm to run.

8. Accessibility and inclusive design

Bake it in from day one. Fixing access at the end costs more and leaves gaps. It is about real people using your site without friction.

We follow WCAG – the Web Content Accessibility Guidelines. Our baseline is Level AA. That standard keeps things usable for most people, most of the time.

How we approach it

Design, content, and build all carry their part. We plan for accessibility in wireframes, set rules for content, and code with care. No bolt-ons later.

Colour contrast and focus states

We choose colours that meet WCAG contrast for text and interface elements. We test light and dark backgrounds. We avoid colour-only cues. Add an icon or text as well so meaning is not lost.

Focus states matter. When you tab, you should see where you are. We keep outlines visible and distinct. We do not remove them for style. If the design is busy, we increase the outline size or add a clear highlight.

Keyboard navigation and skip links

Every interactive part works with a keyboard. Tab order follows the page, not the code’s whims. No popups or menus that trap focus. You can open them, move through them, and close them without a mouse.

We add skip links. A small link appears when you press Tab. It jumps straight to the main content. It saves time for keyboard and screen reader users.

Accessible forms, labels, and error handling

Every field has a clear label tied to the input. Placeholder text is not the label. Required fields are marked with text, not just colour.

Errors show near the field and in a short summary at the top on submit. The message says what went wrong and how to fix it. We keep the user’s input so they do not have to start again.

Buttons read like actions – Submit, Send enquiry, Pay now. Help text sits with the field it explains.

Alt text and media transcripts or captions

Images that add meaning get concise alt text that describes the purpose. Decorative images are flagged as decorative so they are skipped. Charts and complex images link to a short explanation.

Videos have captions. Audio and video have transcripts when content matters for understanding or SEO. If a third party video lacks captions, we add our own or provide a summary beneath.

WCAG-focused checklist and acceptance criteria

What we avoid

Small note – getting this right helps everyone. Clearer content, better forms, fewer support emails. It is worth the effort.

9. Design system and components

A good site feels consistent because it is built from a clear system. Not one-off pages. That system speeds design, build, and content editing. It also reduces bugs. Editors know what to use. Developers know what to extend. Visitors see the same patterns in the same places and move faster.

Typography scale and spacing system

We set a type scale – a small set of text sizes with matching line height and letter spacing. Headings step up in clear grades. Body text stays comfortable to read on all screens. No random sizes added later.

We also use a spacing system – a short list of spacing steps for margins and padding. Think small, medium, large, not 23 different gaps. This keeps rhythm steady and pages tidy. It also makes changes easier. If spacing feels tight, we adjust one value and the whole site benefits.

Grid and layout rules across breakpoints

Pages sit on a grid. The grid is the invisible set of columns that keeps content aligned. Breakpoints are the screen widths where the layout changes to fit the device. We write these rules once and apply them everywhere.

Result – layouts feel stable. Editors can predict how a block will flow at each size. There are fewer surprises on launch day.

Core components with documented states

Components are reusable parts like buttons, forms, cards, navigation, tables, and message banners. Each one is defined once, then reused. We document how each behaves in different states so it stays clear and accessible.

If a new need appears, we extend the component library rather than styling a one-off. This keeps the code lean and the experience predictable.

Iconography rules and usage

Icons support meaning. They are not decoration. We pick one icon set and stick to it so stroke, size, and style match. Icons always sit with text unless the meaning is completely obvious, like a play button.

Content patterns for common messages and CTAs

We define short content patterns for repeat situations. This saves time and keeps tone steady. It also avoids vague links and mixed calls to action.

We save these as WordPress patterns so editors can insert them in a click. Consistency without extra effort.

What we avoid

How this speeds build and editing

The system sets the rules once. Designers work faster with fewer variations to test. Developers ship cleaner code. Editors drop in proven blocks and patterns, not fresh layouts every time. Changes are safer too – update a rule and the benefit rolls across the site.

It is a calm way to build. Less noise. More focus on the message and the task your visitor came to complete.

10. Analytics, events, and consent

Measure what matters and respect privacy. You do not need to track everything. You do need a clear plan, tidy naming, and consent handled properly.

Start with a measurement plan

Tie measurement to your goals and the real journeys people take on the site.

Event and conversion definitions

Events are actions people take on the site. Conversions are the few actions that matter most to the business.

Set only a small set as conversions. Too many conversions makes reporting noisy.

Analytics platform setup

Pick a platform that fits your needs and privacy stance. Google Analytics 4 (GA4) is common and integrates widely. Privacy-focused tools like Matomo or Plausible are good alternatives if you prefer simpler reports or to self host.

UTM and campaign tagging standards

UTMs are short tags you add to a link so analytics can attribute visits to a campaign. They sit after a question mark in a URL. Example: ?utm_source=newsletter&utm_medium=email&utm_campaign=summer_launch

Consent, cookies, and retention

Follow UK privacy rules. If a tracker is not essential for the site to work, ask before you set it. No tricks.

What we avoid

The aim is simple. Trustworthy data that answers clear questions, gathered with respect for your visitors. If a report will never change a decision, we do not build it.

11. Legal and compliance basics

Sort the basics early. It keeps launch on track and avoids rework later. None of this is exciting, but it matters.

Core documents

You will need three clear, accurate documents. Link them in the footer and from your consent banner.

Use templates as a starting point if you like, but get a legal review. Copy-paste text that does not match your setup creates risk.

Cookies – map categories to scripts

Decide which tools sit in which category. Then configure your consent banner and tag manager to match. Only load non-essential tools after consent.

If you also use a Functional category, put live chat and video embeds there. If you use only Necessary, Analytics, and Marketing, place them under Marketing unless they are required for a core task.

Tip – keep a simple table in your cookie policy that lists tool name, purpose, category, provider, and expiry. Update it when you add or remove scripts.

Accessibility statement

Publish a short accessibility statement. Say what standard you aim for, any known issues, and how people can contact you if they need content in another format.

Then act on reports. Fixes are almost always cheaper before launch than after.

DPIA – when you need one

DPIA stands for Data Protection Impact Assessment. It is a short, structured review you complete when processing sensitive data or doing higher risk tracking. The aim is to spot risks early and reduce them.

Keep the DPIA with your project docs. Review it when your data flows change.

Company and contact details

UK sites must make it easy to identify and contact the business. Do not hide the basics behind a form.

Place this on the contact page and in the footer. If you have ever scrambled for a company number on launch day, you know why we do this early.

Cookie banner basics

Avoid delays and risks

Good practice – date your policies, name an owner, and review them at each major site change.

Quick launch checklist

Handle this now and launch runs smoother. It also builds trust, which is hard to win back if you lose it.

12. Environments and workflow We plan the build so work is calm, reversible, and easy to review. No last minute scrambles. No risky shortcuts. Changes move through clear steps and can be undone if needed. Environments We use three environments. Each has a job. Local is the developer’s machine. Fast and safe for early work. Staging is a private test site that mirrors live. It is used for reviews, content entry, and checks. We protect it so search engines do not index it. Production is the live site. It only receives tested, approved changes. This split stops surprises. It also makes issues easier to trace. Version control and review We use Git. Git is a simple change history for code and config. It records who changed what and why. If something breaks, we can step back. Every meaningful change goes into Git. No loose files. No edits only on a server. We use code review. A second pair of eyes checks changes before they move on. This reduces bugs and keeps standards consistent. Reviews look for clarity, security, performance, and the effect on SEO basics like titles, headings, and internal links. Deployments and rollback Deployment means moving approved changes to staging or live. We automate this so the same steps run every time. Fewer mistakes. Faster feedback. Rollback means undoing a release quickly if something goes wrong. We keep a clear rollback plan for each launch and major update. We take a backup before we deploy, and we keep the previous release ready to restore. For live releases we schedule a short window. We test key user paths right after – forms, cart, search, and any custom flows. Issue tracking and cadence We track work in a simple issue tracker. It is a shared list of tasks with owners, notes, and status. Everyone can see progress and what is blocked. On larger projects we use short sprints. A sprint is a one or two week block of focused tasks with a review at the end. Small sites may use a straightforward to-do and weekly check-in instead. The aim is the same – steady, visible progress. Content freeze near launch Close to launch we freeze content and templates. This avoids last minute changes that create bugs or mismatches between staging and live. Typical rules: 3 to 5 working days before launch – no new features or plugin changes. 2 days before launch – content freeze on structure and key pages. Only critical fixes and typos. On launch day – changes wait until post-launch checks are done. If something urgent comes up, we log it, assess risk, and either schedule it or include it with a clear rollback plan. What we avoid Editing on live. FTP-only workflows. No rollback plan. Untracked changes or hotfixes without documentation. Simple flow we follow Plan the change. Write a short note on the why and the impact. Build on local. Commit changes to Git with clear messages. Open a review. Another person checks the work. Deploy to staging automatically. Test function, speed, and SEO basics. Gather feedback. Agree scope for release. Start the content freeze window. Back up live. Deploy to production. Run post-release checks. Monitor and document. If needed, roll back fast and fix on staging. The result is steady work and predictable launches. Fewer surprises. If something breaks at 4 pm, we fix it at 4.15. No one needs a 10 pm rescue.

13. Content production and migration

Content carries your message, wins searches, and converts visitors. We plan how it is created, improved, and moved so you keep equity and do not confuse users or search engines.

Content plan and briefs

We start with a simple plan. Which pages matter most. What they need to achieve. Who they are for.

For priority pages we write a clear brief. A brief is a one page guide for the writer and reviewer. It keeps the page focused and measurable.

AI assisted drafting, with human review

AI can speed up first drafts. We use it where it helps, but we do not publish raw AI copy.

The result reads clean, matches your voice, and stays accurate. AI helps, humans are accountable.

Media optimisation and naming rules

Images and files affect speed and search. We follow simple rules so the library stays tidy and the site loads fast.

These small habits pay off. Pages feel faster and are easier to manage a year from now.

Inventory, pruning, and improvements

Before moving content we make an inventory. Think of it as a list of everything you have. Pages, posts, PDFs, and media.

We protect what works and fix what does not. Copying everything across is easy, but it carries old problems with it.

Redirect map and URL changes

If a page moves, we set a 301 redirect. A 301 is a permanent move that sends people and search engines from the old address to the new one.

This keeps equity and bookmarks intact. It also avoids 404 errors that frustrate users.

Migration workflow and QA

We move content in small batches. Each batch is checked before the next one starts. Calm work beats a big push that hides mistakes.

We also carry across page titles and meta descriptions. These are the title and short summary often shown in search results.

Editorial calendar and approvals

Publishing needs rhythm. We keep a light editorial calendar so work stays visible and on time.

A simple shared sheet is often enough. The key is that everyone knows what is next and who is on the hook.

What we avoid

Do the basics well. Briefs, tidy media, tested redirects, and small batches. You keep your hard won equity and launch without drama.

14. QA, accessibility, and SEO checks

We test calmly and thoroughly before launch. Across devices, browsers, and real user states. The aim is simple – no surprises on go-live.

Pre-launch checklist with owners

Cross-browser and device testing matrix

No desktop-only testing. Real users are on phones, tablets, and different browsers.

Lighthouse and Web Vitals checks

Lighthouse is a built-in audit in Chrome that scores performance, accessibility, and basic SEO. Web Vitals are simple measures of speed and stability. They cover how fast the page shows, how stable it feels, and how quickly it reacts.

Accessibility essentials

Accessibility means everyone can use the site. It also improves general quality.

Structured data validation

Structured data is extra markup that helps search engines understand your content. Think of it as clear labels for things like your business, breadcrumbs, articles, or FAQs.

XML sitemap, robots.txt, and indexing checks

The XML sitemap is a list of your pages for search engines. robots.txt is a simple file that tells crawlers what to fetch. Indexing means your pages are allowed to appear in search.

Forms, errors, and 404s

People need clear feedback when things go wrong. We test both happy and unhappy paths.

Launch timing and sign-off

Avoid Friday afternoon launches. Pick a calm window when the team is available, backups exist, and rollback is clear. We run the checklist together, make a coffee, and only then push live.

15. Launch and early monitoring

We release with a plan. Then we watch the right signals and fix fast. No surprises, no silent launches.

DNS cutover and cache strategy

DNS is the address book that points your domain to the new server. We prepare it so the switch is smooth.

Monitoring and alerts

We do not launch and walk away. We keep eyes on uptime, errors, and 404s. Alerts go to people who can act.

Search Console and analytics verification

Search Console is Google’s dashboard for site health in search. We verify ownership, submit the XML sitemap, and check coverage. Analytics confirms real user activity.

First week – performance and crawl checks

The first week is about stability. Small fixes only. No big content or template changes unless something is broken.

Rollback criteria and process

Sometimes the fastest fix is to roll back. We agree the triggers before launch, so no debate when time is tight.

Process is simple. Restore the last known good backup or switch DNS back to the previous host. Keep cache clears in mind after any switch. Communicate the rollback, log the cause, and schedule a fix before attempting a second launch.

What we avoid

Stay calm, watch the signals, and act quickly. That is how launches stay uneventful, which is exactly what we want.

16. Training, documentation, and maintenance

The goal is simple. Make the site easy to run day to day, without calling a developer for every small change. That takes training, clear notes, and a routine that sticks.

Editor training and short video guides

We train the people who will use the site. Editors get hands-on time with their own content, not dummy posts. We record short videos for the common tasks. Two to five minutes each. No fluff. Just the steps and the why.

Typical topics:

We keep the videos in a shared folder and link them inside the dashboard. If someone forgets a step, the answer is one click away. It saves time and avoids guesswork.

Access and roles

Not everyone needs Admin. In WordPress, roles control what a person can do. Admin can change settings and plugins. Editor can publish content. Author can write their own posts.

This keeps the site safe and reduces accidents. It also makes training simpler, because each person sees only what they need.

Runbooks for updates, backups, and incidents

A runbook is a short checklist anyone can follow. One page, clear steps, links to the right screens. We write three core runbooks.

Updates runbook:

Backups runbook:

Incidents runbook:

These live in a shared document and inside the dashboard. They get updated when the stack changes.

Design and content style guides

Consistency makes a site feel professional and helps with long term SEO. We keep the rules short and practical.

We add examples. One good page is better than a long PDF no one reads.

Maintenance schedule and responsibilities

Agree the rhythm and the owner. Put it on a calendar. Missed maintenance costs more later.

Responsibilities:

On small teams one person may wear two hats. That is fine. Write it down so there is no drift.

Backlog for improvements post-launch

Keep a simple backlog of ideas. A shared spreadsheet is enough. Each item has the page, the change, the reason, and the expected impact.

This keeps momentum without turning the site into a permanent build project.

What we avoid

Train people, write the essentials, and keep a steady maintenance habit. That is how the site stays healthy and useful for years.

17. International and local SEO considerations Plan for geography early. Or keep it simple if you do not need it. If you only serve the UK, focus on local signals. If you serve multiple countries or languages, set the structure before you write a word. If you only serve the UK Keep the setup tight and consistent. This builds trust with search and users. Add your full business details on the site – name, address, phone, hours. Put them on the contact page and in the footer. Use Local Business schema. That is a small block of code that labels your business details for search engines. We add it once and keep it updated. Keep NAP consistency. Your Name, Address, and Phone must match everywhere – site, Google Business Profile, and key directories. Same format, same spelling. Set up Google Business Profile properly. Choose the right primary category, add relevant secondary categories, service area, hours, photos, and a short, clear description. Ask for reviews over time. Create location pages only for real places you serve from – offices, studios, clinics. Do not spin up pages for towns where you have no presence. If you serve multiple countries or languages Decide the structure first. It saves rework later. Then plan content per market, not just translations. Pick a URL approach per market: Subfolders – example.com/uk/, example.com/fr/. Usually simplest to run and share authority across markets.Subdomains – uk.example.com. Works, but splits some signals and adds overhead.Country domains – example.fr, example.de. Strong local signal, but more cost and management. Better if you have real operations and teams in those countries. Use hreflang. This tells search engines which page is for which language or country. For example en-GB for UK English and en-US for US English. We configure it in the head or sitemap so the right version shows in the right market. Localise content, do not just translate. Adjust examples, currency, spelling, measurements, contact options, delivery or service terms, and legal notices. Keep calls to action and forms relevant to the market. Avoid duplicate English variants. If UK and US both use English, make sure each page has clear differences that matter to users. Otherwise they compete in search and both lose. Plan operations details per market. Who answers enquiries, what phone number is shown, and what hours apply. Content should match reality. Hreflang in plain English Hreflang is a tag that pairs equivalent pages across languages or countries. It helps Google send a French user to the French page, and a UK user to the UK page. We set it up once per template and keep the pairs consistent. It reduces duplicate issues and wrong‑market clicks. Local Business schema and NAP Schema is a small data layer that sits behind the page. It confirms your business name, address, phone, hours, and more. NAP is that same set of details. Keep it identical across your site and profiles. Even small differences – Ltd vs Limited, or 0207 vs 020 – can weaken trust signals. Google Business Profile setup Pick the most accurate primary category. Add a few precise secondary ones. Avoid stuffing. Set service areas or a storefront address as it truly is. Do not list cities you do not cover. Add hours, photos, and products or services. Keep them updated. Use the same phone and address format as on your site. Link to the right landing page for that market. Ask for reviews slowly and steadily. Reply to them. It signals care. What to avoid Auto-translation without human review. It creates mistakes and odd phrasing. People notice. Duplicate English variants that cannibalise each other. Different market pages must be meaningfully different. Doorway pages for places you do not serve. If you do not have a presence or offer there, do not build a page for it. If your business is UK only, keep the site lean and local. If you are multi-market, set structure, hreflang, and localisation at the start. It costs less than fixing it later.

18. Budget, trade-offs, and timeline

We plan to ship useful work early, keep costs predictable, and avoid surprises. That means making choices in a clear, shared way. No hidden extras. No drifting scope.

Prioritisation matrix – impact vs effort

We sort tasks by two things: impact and effort. Impact is the real-world benefit – leads, sales, trust, or reduced workload. Effort is the time and complexity to design, build, write, review, and test. We give each a simple score, then decide:

This stops gold plating and keeps us focused on outcomes that matter.

Phased roadmap with acceptance criteria

We work in phases. Each phase has acceptance criteria – a short checklist that defines done. If a test fails the checklist, the phase is not complete.

Phase 0 – decisions and setup

Phase 1 – foundation

Phase 2 – core journeys

Phase 3 – enhancements

Phase 4 – launch and handover

We can adjust phase names and contents to fit your project. The checklist stays.

Cost-benefit for features

Before adding a feature, we ask simple questions:

Examples to ground it:

Rule of thumb: if a feature does not move a key metric, it waits.

Risk log – owners and mitigations

We keep a simple risk log. Each risk has a description, likelihood, impact, owner, mitigation, and a trigger for action. The owner is the person who will deal with it if it happens.

We review the log at each phase gate so nothing sneaks up on us.

Change control for scope shifts

Change control is a light process so changes are clear, priced, and scheduled without chaos.

Minor tweaks that fit the current phase can be batched. Anything larger follows the steps above. No quiet add-ons.

What we avoid

Clear choices save time and money. A simple plan, agreed early, beats a clever plan changed late.

FAQ

How long should planning take before design starts?

It depends on scope, content readiness, and stakeholder availability. Small sites with a single approver move faster. Complex sites or multiple teams take longer. Good planning speeds up design and build because decisions are clear and rework drops.

Do we need final copy and brand assets before planning?

No. Working drafts and core brand elements are enough to start. We need the basics – logo, colours, typography if set, and tone notes. Content and design inform each other, so we shape both in parallel and refine as we go.

Can we use a premium theme and still keep performance?

Yes, if the theme is lean, well supported, and lets you disable extras. Avoid multipurpose bundles that load everything. If you need tight control, high speed, or a strict design system, a custom or block theme is often better. Keep plugins minimal either way.

How much SEO work happens before vs after launch?

Pre-build covers intent research, keyword mapping, site structure, internal linking plan, on-page rules, and redirects. We also set technical basics and tracking. Post-launch focuses on content expansion, optimisation, schema where relevant, and ongoing monitoring in Search Console and analytics.

Where does AI fit in this process?

AI helps with research, briefs, outlines, and first drafts. It can speed audits and produce options to review. Human review is required for facts, brand voice, compliance, and final editing. Treat AI as an assistant, not an author of record.

What if we are redesigning an existing site with rankings?

Start with an audit of URLs, queries, backlinks, and content value. Map redirects before any launch. Keep proven URLs and intent where possible. Test on a staging site, then monitor crawl errors, rankings, and key pages closely after go live.

Do we need special hosting or a CDN?

Choose hosting based on reliability, support, and performance targets. A CDN helps when traffic is national or global, media is heavy, or you need stable speed under load. For local, low-traffic sites it can be optional. Aim for modern PHP, HTTP/2 or HTTP/3, caching, and backups.

Can we phase features to control budget?

Yes. Prioritise by impact on leads, sales, or trust. Ship a stable core first with clean structure and tracking. Add enhancements later on the same foundation, not as rewrites. Keep a backlog and review it at each milestone.

You might like these too

These sit in the same category as the one you are reading. They follow the same thread and offer a bit more depth. Have a look if you want to go further.