How We Structure SEO Into a New Website Build

Most SEO problems we get called in to fix were created during the original build - not because anyone ignored SEO, but because it was treated as a post-launch task instead of a build requirement. Fixing broken information architecture after launch is possible, but it always costs more than getting it right the first time. Here is how we approach it before a single page ships.

Start with information architecture, not templates

Before any design work, we map out every page the site needs, how they relate to each other, and what search terms each page is meant to own. This becomes the site's URL structure and internal linking plan. Getting this right prevents two of the most common problems we see: keyword cannibalization (multiple pages competing for the same search term) and orphaned pages with no internal links pointing to them.

Build technical foundations before content

Clean, descriptive URLs; a single canonical version of every page; proper heading hierarchy starting with one H1 per page; an XML sitemap generated from the actual site structure; and a robots.txt that does not accidentally block important pages. These are boring details, but getting them wrong on day one means every page indexed afterward inherits the mistake.

Treat metadata as a template requirement

Every page template - not just the homepage - needs a defined pattern for title tags, meta descriptions, and Open Graph tags, populated dynamically from content rather than hardcoded. We also add structured data (Schema.org) appropriate to each page type - Organization and WebSite markup sitewide, Service schema on service pages, Article schema on blog posts, FAQPage where there is genuine FAQ content - so search engines can understand the page beyond the visible text.

Performance is an SEO requirement, not a separate task

Core Web Vitals are a ranking factor, so performance budgets get set during the build, not audited afterward. That means image optimization, minimal render-blocking scripts, and server-side rendering are architecture decisions made on day one - see our Core Web Vitals optimization approach for the specifics.

Plan redirects before you need them

Even a brand-new site benefits from thinking about URL stability upfront - once a page is indexed and ranking, changing its URL without a redirect breaks that equity. We document URL patterns as a contract early, so future changes are planned redirects rather than accidental 404s.

Design content templates around search intent

Every page template on the site gets designed around what someone searching for that topic actually needs to see, not just what looks good visually. A service page needs pricing signals, proof, and a clear next step above the fold; a blog post needs a direct answer near the top before the supporting detail. We map search intent to template structure during the content planning phase, so the page layout naturally supports the terms it is meant to rank for instead of fighting against them.

Internal linking is a build decision, not an editorial afterthought

Internal links pass authority between pages and help search engines understand which pages matter most on your site. We build internal linking patterns directly into page templates - related services, related case studies, breadcrumb navigation - so every new page automatically participates in the site's link structure instead of relying on someone remembering to add links manually after the fact.

Why this matters more on a new build than a fix

Every one of these decisions is nearly free to get right during a build and expensive to fix afterward - retrofitting URL structure alone can mean months of ranking volatility. This is why our web development engagements include SEO architecture as a deliverable, not an add-on service quoted separately.