Technical SEO should be decided before design begins because Google and users navigate structure, not colour palettes. If you lock in layouts first, you usually end up forcing content into the wrong hierarchy, burying key pages too deep, and shipping a pretty site that’s hard to crawl, hard to expand, and expensive to fix.
Design is the wrapper. Technical SEO is the floorplan.
Most small business websites don’t fail because the homepage hero image is wrong. They fail because the site can’t clearly answer three questions: what you do, where you do it, and why you’re the right choice. Technical SEO is how you encode those answers into structure, internal links, and metadata so search engines can understand it and people can move through it without friction.
When technical decisions are made after design, you get compromises like “we don’t have room for that page”, “we can’t fit those FAQs”, or “we’ll just put everything under Services”. That’s when rankings plateau and leads become inconsistent.
Sitemap planning: decide the full set of pages before you design templates
A sitemap is not a list you generate at the end. It’s a plan for how customers and Google will traverse your business. Before design starts, you want a working sitemap that reflects real search demand and how people buy.
What to map
- Core money pages: service pages, location pages (if you have physical coverage), product or booking pages.
- Proof pages: case studies, testimonials, gallery, certifications, partners.
- Support pages: FAQs, pricing/finance, process, shipping/returns (where relevant).
- Trust and compliance: privacy policy, terms, accessibility basics.
- Content hubs: blog categories and cornerstone guides that support services.
Once this is mapped, design can create the right page types (templates). Without it, you end up cramming different intents into the same template and weakening relevance.
If your site structure is an afterthought, read Why Website Architecture Matters More Than Design for a deeper breakdown of how structure drives performance.
Content hierarchy: your navigation should mirror how people search
Navigation isn’t just a menu decision. It’s a hierarchy signal. If your most valuable services are hidden under vague buckets, Google and users treat them as less important.
A practical hierarchy for most service businesses
- Top-level: Services, Areas (if needed), Case Studies, About, Insights, Contact.
- Services dropdown: each core service has its own page. Avoid “all-in-one” service pages that try to rank for everything.
- Service page sections: who it’s for, problems it solves, process, inclusions, FAQs, related case study links.
Decide this before design because it affects header layout, footer link blocks, mobile menu behaviour, and internal linking modules. If you leave it until the end, you’ll either oversimplify navigation or create a messy mega-menu to compensate.
Schema mapping: plan structured data while you can still influence the content
Schema is not a plugin box you tick. It’s a mapping exercise between what your business offers and what Google expects to see. Do it early and you’ll create pages that naturally support it. Do it late and you’ll retrofit awkward snippets that don’t match the copy.
Schema types many Australian SMEs should consider mapping early
- LocalBusiness: name, address, service area, opening hours, contact points.
- Service: clear service definitions per page, often paired with FAQs.
- FAQPage: only where questions and answers are genuinely on the page and useful.
- Review: used carefully and honestly. Not every business should mark up reviews on every page.
- Organisation: brand-level details that support trust signals.
Schema mapping also forces good decisions about content ownership. For example, if you want FAQs to support service pages, you’ll design templates that include an FAQ block and editorial rules for keeping them accurate.
Page depth strategy: don’t bury revenue pages
Page depth is how many clicks it takes to reach a page from the homepage. As a rule, your core money pages should be reachable in one to two clicks. That doesn’t mean everything sits in the top navigation. It means you plan internal links, hub pages, and logical pathways.
How to keep depth under control
- Create service hubs: a parent Services page that links to every core service, with short, unique summaries.
- Use related links: on each service page, link to relevant case studies, FAQs, and complementary services.
- Avoid orphan pages: if a page isn’t linked from anywhere meaningful, it won’t perform.
- Be careful with “Resources” dumping grounds: long lists without hierarchy don’t help crawling or conversions.
Depth strategy changes the design. It influences whether you need hub layouts, sidebar navigation, in-page jump links, and how you handle breadcrumbs.
URL and taxonomy decisions: lock these in before designers build components
URL structure and taxonomy (categories and subcategories) are the backbone of internal linking and reporting. Changing them after launch often triggers redirects, broken links, and lost momentum.
Clean structures that scale
- Services: /services/service-name/
- Service areas (only if you truly service them): /locations/city-or-region/
- Case studies: /case-studies/client-or-project/
- Insights: /insights/category/post-name/
Decide early whether locations sit under Services or under Locations, whether blogs are “Insights” or “Blog”, and what the primary category set will be. Designers then create navigation and page layouts that align with that structure, rather than fighting it.
Template planning: SEO requirements should define what each page type must include
Before design begins, define the minimum elements each template needs to rank and convert. This avoids the common situation where a designer delivers a clean layout that doesn’t actually support the content you need.
Example: what a service page template should support
- One clear H1 and sensible heading structure (H2s and H3s that match search intent).
- A section for service-specific FAQs (not generic fluff).
- Space for proof: case study links, testimonials, accreditations.
- Internal links to related services and next steps.
- Fast-loading media rules (image sizing and lazy loading decisions).
This is also where you decide how you’ll handle indexation for thin pages, like short announcements or tag archives. You don’t want design time spent building pages that should never be indexed.
How to run this process without blowing out time or budget
- List your core offers and priority suburbs/regions based on where revenue actually comes from.
- Draft a sitemap with page purpose and primary keyword theme per page (one theme per page, not ten).
- Define navigation and internal linking rules (what must be reachable in 1–2 clicks).
- Map schema per page type so content and templates support it naturally.
- Write or outline cornerstone pages first, then design around real content, not lorem ipsum.
If you want a broader view of how SEO fits into business operations rather than one-off tweaks, SEO Is Not a Tactic. It’s Infrastructure for Australian Small Businesses is worth a read.
What you get when you decide technical SEO first
- Cleaner builds because templates are designed for real content and crawl paths.
- Better rankings earlier because Google can understand the site without guesswork.
- Lower cost of change because you’re not redesigning navigation and rewriting URLs post-launch.
- More consistent leads because key pages are easy to find and clearly mapped to intent.
Good design still matters. It just shouldn’t be the first domino.
Sources & Further Reading
- Google Search Central: SEO Starter Guide
- Moz: The Beginner's Guide to SEO - Site Architecture
- Australian Government Digital Transformation Agency: Web Content Accessibility Guidelines (WCAG)
- HubSpot: How to Create a Website Sitemap for SEO
- Search Engine Journal: Why Technical SEO Should Come Before Design
- Australian Small Business and Family Enterprise Ombudsman: Digital Marketing Guide
Engineer First. Design Second.
Technical structure must be mapped before visual design to ensure search performance and scalability. Our build process prioritises architecture from day one.
See Our Structured Development ProcessComments
No comments yet. Be the first to join the conversation!
Leave a Comment
Your email address will not be published. Required fields are marked *