What to ask a web design agency about search

// In this article+

A web design agency builds the templates, the navigation, and the code a site runs on. Whether that build helps organic search or hurts it gets decided before the contract, not after. Google's own hiring guidance ↗︎ names the moment directly: "a great time to hire is when you're considering a site redesign (the earlier, the better)".

That guidance describes a two-way review, not a one-sided interview. A design team needs search history, priority URLs, and content structure handed to it before the first wireframe. A search strategist needs heading rules, performance targets, and access commitments handed back. Neither side gets what it needs from a list of gotcha questions on a sales call.

What should you ask a web design agency about search before you sign?

The review runs in two directions. Design has to know what already ranks, and why, before it redraws the site. Search has to know what the new templates will support, and what they will not, before it promises anything to a client or a boss. Treating this as one list of questions from a buyer to a vendor misses half the exchange.

Google's hiring guidance frames a redesign as the most consequential moment to bring search into the room. The reason is simple. Decisions made now get baked into templates. Templates are expensive to unwind later. That is why this review belongs before the contract, not at launch. Launch week has its own document, an SEO migration checklist for launch week. It covers redirects, canonicals, and sign-off gates once the build already exists. The broader discipline those steps sit inside is technical SEO. It covers audits, canonicals, and Core Web Vitals as a standing program. This piece sits upstream of all of it. It covers the decisions a wireframe locks in, before there is anything to migrate or audit.

A short version of the two-way exchange:

• Design hands search: current top-traffic URLs, their target terms, Search Console history, and any existing redirect chains.
• Search hands design: heading rules, numeric performance targets, and the schema types the templates need to support at build.

What does a design team need from search before the wireframes start?

Google's hiring guide ↗︎ describes an SEO reviewing a site's content, its structure, its technical development, and its redirects as part of a proper engagement. A design agency cannot do that work for a site it has not seen ranking yet. It needs the history handed to it. Not rebuilt from a guess.

Responsival's review of design-agency practice in 2026 ↗︎ names the failure mode. Agencies tend to treat search as an add-on. It gets applied after the templates are drawn, rather than built into the architecture and the navigation from the start. A navigation menu decided in a design tool, with no reference to which categories actually earn traffic, is that failure in practice.

The worked fix is a one-page brief. It goes to the design agency before the kickoff call, not after. It lists:

• The current top 20 to 50 URLs by organic traffic, pulled from Search Console.
• The target keyword or topic each one currently ranks for.
• Any URL patterns that must survive the redesign unchanged, and any known candidates for consolidation.
• Faceted navigation, parameterized URLs, and canonical tags already in use, so the new templates do not reintroduce a duplicate-content problem the old site already solved.

That brief is the input. Without it, a design agency draws a sitemap from instinct instead of from evidence.

What does search need back from the design team?

The exchange runs the other way too. A design team has to commit to specifics. A search strategist has to be able to hold it to them. State them as numbers wherever a number exists, not as adjectives like "fast" or "clean."

Heading structure a template can't break

Search relies on a page's heading levels, H1 through H6, to understand what a page covers and how its sections relate. The W3C's own accessibility guidance ↗︎ states the rule plainly, for anyone building a template: "Make sure that a <h2> is not followed directly by an <h4>, for example". A template can break that rule silently. It happens when a content editor applies an H4-styled visual treatment without actually nesting it under an H3. The break repeats on every page built from that template. Test one sample template against the rule before signing. Not after a hundred pages exist.

Core Web Vitals targets stated as numbers, not adjectives

Core Web Vitals are Google's set of page-experience metrics. Google's web.dev documentation on the vitals ↗︎ states three thresholds directly: "LCP should occur within 2.5 seconds of when the page first starts loading", INP should be 200 milliseconds or less, and CLS should be 0.1 or less. LCP is Largest Contentful Paint. It is the time until the biggest visible element loads. CLS is Cumulative Layout Shift. It measures how much the page jumps around as it loads. INP is Interaction to Next Paint. It measures how long the page takes to respond after a click or tap. Those numbers get measured across real visits, not a single lab test. They are the targets to put in the brief. "Make it fast" is not a target an agency can be held to.

Where schema markup gets decided, and who owns it

Schema markup is structured data added to a page's code. It names the page's content in a machine-readable vocabulary, such as marking a page as an Article, a Product, or a LocalBusiness. The vocabulary itself is governed outside any one agency, per Schema.org's own documentation ↗︎: "Since April 2015, the W3C Schema.org Community Group is the main forum for schema collaboration". Templates decide which fields exist to hold that data. A product template with no field for price, availability, or review count cannot carry Product schema. It does not matter how the page reads to a visitor. Deciding which schema types the templates support is a build-time decision, not a post-launch patch.

Three numeric asks belong in the request for proposal, the RFP, before a design agency is chosen:

1. The LCP, INP, and CLS targets the build will meet, stated as numbers.
2. The heading-nesting rule the templates will enforce.
3. The schema types committed to at build, named by type.

Who should own Search Console, Analytics and the CMS after launch?

Ownership of the accounts that measure a site is a separate question from who builds it. It is also where the review most often gets skipped.

Verified owner vs. delegated owner vs. full user

Google Search Console's own permissions model names distinct roles. A verified owner proves ownership directly, through a token placed on the domain or the site. A delegated owner is different. Google's Search Console permissions documentation ↗︎ states the definition plainly: "Someone granted ownership status by a verified owner without the use of a verification token". Below owner sits a full user. A full user can see most reports and settings, but cannot grant access to anyone else. The buyer's account should hold verified ownership. An agency can operate under delegated owner or full user status, added by the buyer, not the other way around.

What 'you own the code' should say in the contract

Rank-Truth's hiring checklist ↗︎ states the access rule without softening it: "Do not hire an agency that will not give you Owner access to Google Search Console and Admin access to GA4". Outpace SEO's guide to signing an SEO contract ↗︎ frames the same rule as a test of trust: "A trustworthy agency will insist that all work, content, and data belong to your business". The same principle applies to the CMS, the content management system, and the domain registrar. If the only login belongs to the agency, the buyer does not own the site. It rents access to it.

This is the same handoff a website migration SEO engagement has to resolve before a single redirect goes live. Who holds the login on day one. What happens to it if the relationship ends. Both sources point to the same contract term: owner-level access granted at kickoff, and an exit clause the buyer can trigger on 30 to 60 days' notice, rather than a login that only the agency ever held.

An access checklist worth running before a signature, not after an agency disappears:

• Search Console: buyer holds verified owner status, agency added as a user.
• GA4: buyer holds admin access under its own account, agency added as a user.
• CMS and hosting: buyer's account is the primary account of record.
• Domain registrar: buyer's name and email are on the record, not the agency's.
• Exit clause: a stated notice period, 30 to 60 days, that returns full access without renegotiation.

Which answers separate a real agency from a vague one?

Kreativa Group's hiring checklist ↗︎ includes a direct question worth asking on the first call: "How do you approach SEO and performance during the build?" Top Floor's development-agency checklist ↗︎ asks a version of the same question: "What's your process for optimizing the website for search, including AI and generative search?" Both are useful for the same reason. A vague answer is easy to spot.

Responsival's critique of 2026 agency practice ↗︎ names the pattern behind the vague answers. Agencies treat responsive design as sufficient on its own. They think only in keywords, rather than entities and structure. They ship with no schema plan at all. A guaranteed-rankings promise, an agency that insists on owning the analytics account, and a template with no heading or schema plan are the same red flag stated three ways. Nothing here is measured. Nothing here can be held to a number.

What to do this week

1. Write the one-page search brief before the kickoff call. List top-traffic URLs, their target keywords, and any existing canonical or redirect patterns.
2. Request Search Console owner access and GA4 admin access under your own account. Add the agency as a user, not the reverse, before any design work starts.
3. Put LCP, INP, and CLS targets and a heading-nesting rule into the RFP as numbers. Test one sample template against them before signing.
4. Ask who owns the schema markup plan, by type, and get the answer in writing.
5. Cap the initial contract at six months with a 30 to 60 day exit clause that returns full account access without renegotiation.

FAQ

Is a web design agency the same as an SEO agency?

No. Google's hiring guidance treats search as a distinct discipline. A business may need to bring it in separately, whether or not the design agency carries it in-house. Some design agencies employ search specialists. Many do not. They subcontract the discipline, or skip it entirely. Confirm which is true at the brief stage, not after templates ship.

Do I need to hire an SEO before or after choosing a design agency?

Before, if possible. Google's own guidance is specific about the timing: "a great time to hire is when you're considering a site redesign (the earlier, the better)". Bringing search into the room after wireframes are approved means renegotiating decisions that are already built.

What if the design agency says SEO is handled automatically by the platform?

Treat that answer as the vague answer from the table above. Responsival's review states the specific gap plainly: "Responsive design does not necessarily translate to mobile optimization for many organizations". A platform can enforce a responsive layout. It does not have to enforce a heading rule, a Core Web Vitals target, or a schema plan. Ask for the specifics anyway.