E-commerce agency: the SEO decisions of a build or a redesign

A merchant build or redesign is decided long before it goes live. At the point where the templates are drawn and the URL rules are fixed, design decisions (templates, facets, variants, navigation) become visibility decisions.

This page is for the marketing director or executive who has to brief an e-commerce agency on a build or a redesign, and decide in which order URL rules, templates, redirects, validation before go-live and tracking are settled.

It specifies who carries each decision and what authorizes go-live, as a complement to the criteria for choosing an SEO agency. Their order and their controls determine whether the site that opens keeps the acquisition the old one had built.

What is decided on the SEO side before the wireframes

SEO by design means building visibility prerequisites in at the point where they cost the least: when the templates are drawn and the URL rules are defined. A rule set at that moment is specified once; the same rule set after go-live is caught up page by page, on a catalogue that has grown in the meantime.

The stake is not theoretical: visibility is heavily concentrated on the first positions. According to our SEO statistics, the click-through rate on page 2 of the SERPs is 0.78% (Ahrefs, 2025). A family of pages that leaves the index or loses its history does not slip one notch: it leaves the zone where traffic exists.

Hence a chronology, and the points beyond which a decision becomes expensive to correct:

• URL rules before templates: once the templates are approved, changing the URL structure means reopening the wireframe, the navigation and the redirect plan.
• Templates before content production: a field forgotten in the CMS is caught up on ten product pages, not on ten thousand.
• Redirects before final validation: a plan built during the last checks cannot be verified in the time left.
• The tagging plan before go-live: a conversion that goes unmeasured on day one cannot be reconstructed retroactively.

The budget consequence is nothing like a quote line item: you have to plan for three things, so that acquisition can be rolled out without permanent rebuilding:

• Reliable tracking.
• Stable pages.
• “Usable” templates: content, structured data, FAQ.

Who decides what, and who declares a blocker

A merchant project brings together people who do not carry the same consequences. The split is set at scoping, in writing, role by role: that is what makes it possible to hold a rule six months later, when the date is approaching and decisions accelerate.

Three rules then frame blockers:

• Any role can declare a blocker.
• One role alone settles it.
• The decision is written down with the consequence that was accepted.

Architecture foundations: templates, site structure and depth

Architecture is not a “documentation” deliverable: it determines discoverability (for users and for bots), conversion and maintainability. A shop quickly generates a very large volume of URLs (categories, product pages, facets, pagination, variants), and every promotion, every new product, every added module produces new ones without any editorial decision having been taken.

The rule is therefore set on the template, once, rather than on the URLs it will produce. Three of them are settled before the wireframes:

• Categories as hubs: transactional pillar pages (stable, linked, easy to find) that structure browsing and merchandising.
• Depth rule: aim for access to the key pages in about three clicks, to limit “leaks” and speed up indexing.
• Native internal linking: menus, breadcrumbs, category links, “best-sellers” and “related products” blocks, while avoiding the injection of sort URLs or uncontrolled parameters.

A category created two years later then inherits the hub, the depth and the internal linking. Once the site is open, the subject changes nature and becomes the steering of an installed catalogue: that is what an e-commerce SEO agency covers on a live catalogue, categories, facets, product pages and measurement.

The CMS fields to plan before content production

A template is the list of fields the catalogue and the editorial team will be able to fill, not a wireframe. On a product page, three families of fields have to be planned at minimum:

That list is the raw material of the structured data and of the answers the engines will come looking for. A field missing from the template becomes a field missing from the whole catalogue, and adding it later means going back over every product page.

It also makes the production chain of a large catalogue reliable: opportunities, briefs, planning, production, approval, publication. With templates and fields planned at the design stage, every step has somewhere to be written; without them, the chain ends in manual entry and consistency is lost at the first thousand product pages.

URL and indexing rules: what is specified on the template

SEO is handled here as product rules: URL governance, templates, indexability, sitemap, canonicals, internal linking. That is specified at template level (once) rather than URL by URL (endlessly).

It is the answer to the objection heard in project meetings, “SEO is going to slow the sprints down”: what slows a sprint down is a rule discovered along the way. Four decisions cover the essentials:

• Clean templates: one template per page type (category, product, selected facet, editorial content), with dedicated fields.
• Indexability: deciding which families of pages should be indexed, crawlable or consolidated.
• Canonicals: setting the rules for variants, filters and parameters.
• Sitemap: listing only canonical URLs intended for the index.

Each one is re-read at acceptance and produces a verifiable finding: a family of pages is indexable or it is not, a sitemap contains non-canonical URLs or it does not. That verifiability is what tells them apart from an intention.

Useful facets, noisy facets: the shared decision

Faceted filters are indispensable for the user, but have to be governed technically to avoid an explosion of near-duplicate URLs. The principle is settled on the template: not every combination should become indexable.

You select the ones that match a stable, profitable intent (a material, a size, a price range that people genuinely search for and that the catalogue can serve all year round); the others stay available to the user without entering the index.

The resulting split holds for the whole project:

If the first two decisions are not taken together, one undoes the other in production. Catalogue steering is covered in the article on the e-commerce SEO agency.

Structured data, product master data and citability

Structured data helps engines understand price, availability, reviews, navigation hierarchy and variants. In a generative context, it also makes it easier to produce comparisons and to cite product information. Its integration therefore has to be planned at template level, not “page by page”: markup set product page by product page degrades at the first change of template.

That markup is only worth what the data it exposes is worth. From the design stage, you have to define four elements:

• The product master data.
• The synchronization rules: stock and price.
• The identifiers.
• The responsibilities: who “prevails”.

Without that groundwork, a wrong price in one system ends up published, marked up, then taken up as it stands in a generated answer.

Three conditions complete the setup, and they are decided on the template, not at proofreading:

• Readable structure: clear sections, lists, FAQ, a consistent hierarchy.
• Evidence: trust information (returns, guarantees, availability, terms) that is easy to extract.
• Entities and attributes: well-structured product characteristics (material, dimensions, compatibilities, and so on).

The first is not a layout preference: how generative engines select and reuse pages is detailed in our GEO statistics. A template that imposes that hierarchy and positions the evidence blocks produces that structure across the whole catalogue, not only on the product pages someone has taken care over.

Redesign: auditing what exists and the redirect plan

A redesign with no audit is a risk taken. The audit has to cover six areas:

• Templates.
• Performance.
• Data.
• Modules.
• IT dependencies.
• URL rules: facets, pagination, variants.

To frame that phase and to know what level of evidence to expect from it, our guide on what an agency SEO audit has to deliver on SEO and GEO gives the deliverables to ask for, useful even when the project’s stated priority lies elsewhere, because indexability mistakes are paid for afterwards.

The migration plan, for its part, has to handle separately:

• Catalogue data (products, attributes, media, SEO fields, variants).
• Customer data (accounts, consents, history).
• Orders (statuses, invoices, after-sales).
• Tracking (GA4, events, conversions), with before/after tests.

Handling them separately comes down to a simple reason: each batch has its owner, its migration date and its verification test. A batch that fails is seen before go-live rather than in next month’s figures.

Migration priority is set at the same moment, and it goes to the pages that carry business weight: the categories and the top products, which carry most of the acquisition already earned.

Redirects, a design object and not a fix

301 redirects are a migration design subject, not a post-launch patch. The plan has one line per old URL, and for each of them one of the three possible fates:

• Kept as it is.
• Redirected to its equivalent.
• Deleted with no equivalent, and accepted as such.

A plan that only lists the redirects leaves the other two cases out of control. Three rules and one verification are enough to make it a workable plan:

• Build it while the new URLs are being decided, on an exhaustive export of what exists and not from memory.
• Avoid any redirect chains.
• Also fix the internal links pointing to intermediate URLs: an internal link left on an old address keeps alive the chain you thought you had removed, and maintains it through every subsequent migration.
• Verify before go-live, on a representative sample, that every priority old URL lands in one redirect on an equivalent page, not on the home page nor on a generic category: needless 404 errors lose acquisition and degrade the experience, and a redirect that lands anywhere other than the equivalent has the same effect, without signalling it.

The acceptance check before go-live, and the verifications that follow

A useful validation is not limited to “visual” checks. It rests on three requirements:

• Concrete criteria: performance, errors, rendering, tracking.
• Continuity, in addition on a redesign: data, tracking, technical performance, and the absence of regressions.
• Verifiable deliverables rather than a general promise: that is the principle that makes it enforceable.

Mobile accounts for around 60% of global web traffic (Webnyxt, 2026): the checks are run on mobile as much as on the desk of whoever runs them.

What authorizes go-live, and what is checked afterwards

Validation before go-live is the only moment when a launch date is discussed with facts. It covers at minimum five points:

• Indexing: the protections inherited from staging (robots blocking, authentication, template noindex) are lifted on production at launch, staging stays protected, and every family of pages complies with the rule decided at scoping.
• Canonicals and sitemap: the two are consistent, and the sitemap contains only canonical URLs intended for the index.
• Redirects: the plan is complete, with no chains, and tested on the priority pages.
• Tracking: the tagging plan is replayed, e-commerce events fire, consent is in place.
• Performance: budgets are held on the most visited templates, knowing that the mobile abandonment rate reaches 53% when loading goes beyond three seconds (Google, 2025).

Each point receives a verdict, and only three exist:

• Compliant.
• Non-compliant: the point is documented and goes into the first post-go-live batch, with a deadline.
• Non-compliant and blocking: the point is handled before the date, not after, and that is what tells a validation apart from a list of reservations.

After go-live, you have to check quickly: indexing, errors, performance, checkout, tracking, and canonical/sitemap consistency. The aim is to spot regressions early, before they turn into a drop in conversion or a loss of crawling. On large-catalogue projects, server log analysis can help understand what the bots actually crawl, particularly on pagination and parameters.

Measurement continuity: tagging, consent and steering

Tracking quality is decided at build, not afterwards. A shop can look “profitable”… until the day the data no longer explains a drop in conversion. You therefore have to plan, on the same footing as the URL rules and at the same moment:

• A tagging plan.
• Consistent e-commerce events.
• Analytics acceptance tests.

Compliance is part of that continuity: the GDPR also applies to tracking, and consent as much as collection quality has to be thought through before go-live. A banner put up the day before go-live changes what is measured and makes the weeks before and the weeks after incomparable.

The minimum viable steering after go-live

Steering rests on two sources and one condition:

A conversion defined after the fact cannot be caught up on the history. A tracking regression is for that reason more costly than it looks: it does not directly lose revenue, it causes bad decisions for the whole time nobody has seen it.

Depending on your situation, two further reads extend this page. The site is live and the investment has to be justified: if the board asks what the redesign brought in on organic, the subject becomes measurement, and the calculation and steering of SEO ROI give the method. The catalogue has to be steered after go-live: facets to open, product pages to produce, measurement to hold over time, that is the scope of an e-commerce SEO consultant.

On checking indexing and canonicals, a 360 SEO and GEO audit module acts as a safety net before and after go-live: it puts numbers on the gap between the rule decided at scoping and what the site actually produces.

FAQ: frequently asked questions

What is the difference between an e-commerce agency and an SEO/GEO agency?

An e-commerce agency (build and development) designs, develops and maintains the shop. An SEO/GEO agency concentrates on visibility (SERPs and generative engines), content strategy, authority, and performance steering. The two are complementary, but their core business is not the same. Ideally, you build the SEO/GEO prerequisites in from the design stage to avoid costly fixes.

Who sets the URL rules, who implements them and who verifies them?

The SEO owner sets the rules at template level, before the wireframes. The technical team decides how they translate into the platform and implements them. Validation before go-live falls to whoever set the rules, with a formal verdict. Go-live is approved by the project sponsor, on the basis of that verdict. Every role can declare a blocker; one role alone settles it, in writing.

What authorizes go-live, and who decides it?

A validation where every point carries a verdict: compliant, non-compliant, non-compliant and blocking. The points checked at minimum are indexing, canonical/sitemap consistency, the redirect plan, tracking and the performance budgets. A blocking point is handled before the go-live date, not after. The decision to go live belongs to the project sponsor, on the basis of that verdict.

How do you avoid losing tracking during a redesign?

By treating tagging as a migration batch in its own right: a written tagging plan, consistent e-commerce events, tests before and after. Consent and collection quality are decided before go-live, otherwise the weeks before and the weeks after are no longer comparable. A conversion defined after the fact cannot be caught up on the history.

How do you prepare GEO from the design stage for LLMs?

By structuring the information so that it is “reusable”: clear sections, lists, FAQ, normalized product data, evidence (delivery, returns, guarantees), and structured data. The aim is to make your pages easy to interpret and to cite. These rules are set at template level, so that they apply to the whole catalogue and not only to the product pages that have been reworked.

Which indicators should you track after go-live (Google Analytics, Google Search Console)?

Google Search Console gives indexing, impressions, clicks, CTR, queries and pages, as well as errors and sitemap status. Google Analytics gives the conversion rate (by device and by channel), basket abandonment, revenue, engagement and funnel steps. Technical quality is tracked separately: Core Web Vitals, checkout errors, availability and response time.