Before you commit a budget, you make a series of decisions that determine whether your new site can earn attention from Google at all. SEO friendly website design is not a coat of paint applied after the layout is approved; it is a set of structural choices about navigation, URLs, page types, and crawlable links that are cheap to get right at the wireframe stage and expensive to unwind later. This article is about the build. It is not about hiring a combined design-and-search firm, and it is not about repairing a live site that has already lost visibility — those are different projects with different scopes, and mixing them up is how budgets get wasted.

If you already run a site and want to understand the ongoing work, start with our SEO services overview instead. If you want the two disciplines handled together from day one, see website design and SEO. What follows assumes you are planning a new build and want the structural decisions settled before a designer opens a canvas.

Define the Site's Purpose and Conversion Paths Before Design

Google's own SEO Starter Guide frames the discipline plainly: SEO is about helping search engines understand your content and helping users decide whether to visit. That definition is useful because it pushes the first decision away from aesthetics and toward intent. What is each page for?

For your B2B site, choose a primary action for each page: request a quote, book a call, submit a form, or call. The right choice depends on what your buyers need at that point. Decide which action belongs on which page type before anyone designs a template. A service page should not carry the same call to action as a case study, and a case study should not carry the same call to action as a careers page.

A practical way to force this: build a short table mapping page type to conversion action to required content.

Page type Primary conversion action Content required at launch
Service / capability page Request a quote Scope description, process, proof, FAQ
Location or service-area page Call or form Areas served, local proof, contact details
Case study Book a call Problem, approach, outcome, related service link
About / team Contact Who you are, credentials, real address
Contact Form submission Form, phone, hours, map or directions

Two decisions fall out of this table. First, what must exist at launch versus what can wait. A thin site with five complete pages beats a twenty-page site where twelve pages are stubs. Second, how conversion paths shape navigation. If quote requests are your priority, the quote path needs to be reachable from every template — header, footer, and inline within body copy.

Information Architecture and URL Structure Decisions

Information architecture is where most rebuilds quietly go wrong. The temptation is to mirror your internal org chart; the better approach is to mirror how customers describe what they need.

Google publishes URL structure best practices and the guidance is refreshingly concrete. URLs must follow IETF STD 66, and reserved characters must be percent encoded. Beyond that, Google recommends descriptive URLs that are easy to understand. For a US B2B firm, that means using the words your buyers actually type: /commercial-roof-repair/ rather than /svc-04/, and /industrial-pumps/centrifugal/ rather than /products/?cat=17&sub=4.

Flat versus deep is a real tradeoff, and there is no universal answer. A flat structure — everything one or two clicks from the homepage — is easier to crawl and easier for visitors to scan, but it stops scaling once you have dozens of service lines or hundreds of products. A deeper structure organizes large catalogs cleanly but buries pages and dilutes internal linking if you are careless. A reasonable rule of thumb: keep any page that matters commercially within three clicks of the homepage, and use subfolders to group related offerings rather than to reflect internal departments.

Two decisions deserve early attention because they are painful to reverse:

Do not use URL fragments to change content. Google states plainly that Search generally does not support URL fragments for content changes — a URL like https://example.com/#/services is a problem. If your build uses JavaScript to swap content, the correct approach is the History API, not a hash route.

Plan redirects and canonicals before launch, not after. If you are replacing an existing site, every URL that changes needs a mapped destination. Build that mapping spreadsheet during IA planning, while you still remember why pages existed. Canonical decisions — which version of a page is the one you want indexed — should be settled alongside the URL plan, particularly if you will have filtered category pages or paginated archives.

Multilingual and multi-region builds add a layer here. Decide folder strategy (/es/, /mx/) versus subdomain before design, because it affects navigation, hreflang implementation, and how your sitemap is generated.

Crawlable Navigation and Internal Linking Choices

This is the section most likely to be undermined by a well-meaning front-end developer. Google's documentation on link best practices is explicit: Google can generally only crawl a link if it is an <a> HTML element with an href attribute. Links built from script events, or <a> tags with routerLink and no href, may not be parsed reliably.

Practically, that means your primary navigation, breadcrumbs, footer links, and in-body links should render as real anchor elements with real URLs. A dropdown menu that only works via a click handler and never emits an href is a navigation dead end for crawlers.

Anchor text matters too. Google uses anchor text to understand what the destination page is about, and it advises against empty link text. "Click here" tells a crawler nothing; "commercial roof repair in Ohio" tells it a great deal. Apply the same standard to image links — Google uses the img element's alt attribute as anchor text, so a linked logo without alt text is a wasted signal.

Three decisions to lock down:

  1. Navigation implementation. Confirm with your developer that every nav item is an anchor with an href pointing at a resolvable URL. Test by disabling JavaScript in a browser and seeing whether you can still reach every important page.
  2. Breadcrumbs. For any site with more than one level of hierarchy, breadcrumbs give crawlers and users a clear path. They also reinforce your IA in the HTML.
  3. Orphan page prevention. Before launch, list every page in your sitemap and identify at least one internal link pointing to it from a crawlable page. Pages reachable only from a sitemap file, or only from a search box, are effectively orphaned.

Internal linking is also how you distribute authority to the pages that need it. If your money pages are your service and location pages, they should receive more internal links than your blog archive.

Design Decisions That Affect Indexing and Rendering

Some design and build choices have direct indexing consequences, and they are worth naming separately because they get lost in general "make it fast and pretty" advice.

Fragments versus History API. Covered above, but worth repeating as a build decision: if your designer proposes a single-page scrolling experience with hash-based section links for distinct content, push back. Distinct content deserves distinct URLs.

Rendered HTML. If your build relies on client-side rendering, confirm what a crawler actually receives. The safest posture for a small B2B site is server-rendered or statically generated HTML for anything commercially important.

Parameters versus path segments. Google supports query parameters and specifies a common encoding — an equals sign to separate key-value pairs and an ampersand to add more. That does not mean parameters are the better choice for your main service pages. Use path segments for stable, indexable content and reserve parameters for sorting and filtering.

URLs must resolve. Google notes that the URL in an anchor element must resolve into an actual web address. Placeholder links like href="javascript:goTo('products')" are not reliable. During QA, click every link and confirm it lands somewhere real.

Pre-Launch QA Checklist for SEO-Relevant Design Elements

Run this before DNS changes, not after. Fixing these items post-launch means re-crawling, re-indexing, and sometimes a visible dip while Google reconciles the change.

Check What to verify Why it matters
Crawlable links Nav, footer, breadcrumbs, body links are <a href="..."> Google may not parse script-only links
Resolving URLs Every href returns a real page, not a JS handler Unresolvable links cannot be crawled
URL structure Descriptive paths match the planned IA Helps Google and users understand the site
No fragment routing Content changes use History API, not #/ routes Search generally does not support fragments
Anchor text Descriptive, not "click here" or empty Tells Google what the destination is about
Image alt text Linked images have descriptive alt attributes Alt text serves as anchor text for image links
Redirect map Every changed URL has a mapped destination Preserves accumulated signals
Canonicals One preferred URL per page, consistently declared Prevents duplicate-version confusion
Sitemap and robots Sitemap lists canonical, indexable URLs; robots.txt does not block key paths Controls what gets discovered
Indexability No stray noindex on pages you want found A single tag can remove a page from results

On timelines: Google notes that changes can take effect in a few hours or several months, and suggests waiting a few weeks before assessing whether your work had a beneficial effect. Plan for that. Do not judge a launch by week one, and do not let anyone promise you a ranking position as a deliverable.

A worked example, explicitly hypothetical: a 12-person industrial equipment repair firm in the Midwest replaces a five-page brochure site. The IA plan calls for four service pages, three service-area pages, an about page, and a contact page. During QA, the team finds that the service-area dropdown emits routerLink without href — crawlers cannot follow it. They also find that the old /services.html URL has no redirect. Both are caught during pre-launch QA rather than discovered after customers or crawlers hit the new site. That is the entire value of pre-build decisions: they convert future problems into a checklist item.

If you would rather have the design and the search work planned as one project, our website design service covers the build with these decisions built in. If you are still deciding whether you need a new site or a repair, the SEO services page describes what ongoing optimization looks like.

FAQ

What decisions should I make before starting an SEO-friendly website design project?

Settle six things before design begins: your primary conversion action for each page type, the page types you will launch with, your information architecture and URL structure, how navigation and internal links will be implemented in HTML, your redirect and canonical plan if you are replacing an existing site, and your pre-launch QA checklist. Google's SEO Starter Guide is a reasonable baseline for what "eligible to appear" requires. None of this guarantees rankings or traffic — Google is explicit that there is no secret to ranking first — but it removes structural obstacles that are costly to fix later.

How does URL structure affect SEO during a website redesign?

URLs are how Google identifies and revisits your pages, so changing them during a redesign means re-establishing that identity. Google's URL structure guidance asks for URLs that follow IETF STD 66, use descriptive words, and avoid fragments for content changes. In a redesign, the practical work is building a redirect map for every URL that changes and deciding canonicals for any page that could exist at more than one address. Descriptive URLs help users and search engines understand your site; they are not a ranking lever on their own.

What should I check before launching a new website to ensure it is crawlable and indexable?

Verify that navigation, breadcrumbs, footer links, and body links are real anchor elements with href attributes pointing at resolvable URLs, per Google's link best practices. Confirm anchor text is descriptive and that linked images carry alt text. Check that no page you want indexed carries a noindex directive, that your sitemap lists canonical URLs, and that robots.txt does not block important paths. Confirm content changes use the History API rather than URL fragments. Finally, remember Google's own note that changes may take weeks or months to show up — a clean launch is a starting condition, not a result.

Is this the same as hiring a combined design-and-SEO service?

No. A combined service bundles the build and the ongoing optimization into one engagement. The decisions in this article belong to the build phase specifically — they are the structural choices that either make later optimization possible or fight against it. Fixing a live site that has lost visibility is a third, separate scope. Being clear about which project you are buying keeps expectations and budgets aligned.

Sources