An online store is one of the few builds where a technical decision made in week two can quietly cost you revenue for years. URL structure, how variants and facets are handled, how product data is marked up and how fast the pages render are not finishing touches; they determine whether the catalogue can be found at all. Most rebuild disasters are not design failures, they are migration failures. This page covers what a competent development engagement handles, what to write into the contract, and how to check the work before you pay the final invoice.
Search-critical decisions made during the build
Google publishes documentation specifically for ecommerce sites, and it covers the decisions that are expensive to reverse. URL structure for products and categories. How to handle variants, so colours and sizes do not become thousands of near duplicate pages competing with each other. Faceted navigation, which can generate an effectively unlimited crawlable URL space if filters are linked carelessly. Pagination and how a large catalogue is made discoverable. Product structured data, so listings can carry price and availability where those appear on the page. Out-of-stock and discontinued product handling, which most builds ignore until the first seasonal cycle. Ask a development candidate to walk through each of these before quoting. A team that answers fluently has shipped stores; a team that treats them as post-launch SEO work has shipped brochures.
Speed is a requirement, not a nice-to-have
Core Web Vitals give you a shared vocabulary and thresholds you can hold a build to: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or below 0.1, each measured at the 75th percentile of real page loads. Write those numbers into the acceptance criteria for the template types that matter most, meaning home, category, product and checkout, measured on a mid-range mobile device rather than a developer laptop. Also agree a page weight budget, because the usual cause of a slow store is not the platform but the accumulation of tags, chat widgets, review scripts and personalisation snippets added after launch. A team that accepts measurable performance criteria upfront will build differently from one that promises to optimise later.
Migration is where the losses happen
If you are replatforming, the migration plan matters more than the design. It needs a complete inventory of existing URLs, a mapping of every one to its new destination, permanent redirects implemented server-side, preserved canonical logic, an updated sitemap, and a check that the staging site was not indexable. It needs the analytics and conversion tracking rebuilt and verified before switchover, not after. And it needs a monitoring window afterwards where crawl errors and indexed page counts are watched daily for a few weeks. Ask a candidate for their migration checklist as a document. If they cannot produce one, they have not done enough migrations to have written it down. Ask who is on call in the week after launch and what the rollback plan is.
Contract terms that matter
Own the code, the repository and the hosting accounts. Insist on a staging environment and a documented deployment process rather than edits made on production. Agree what happens to third party licences on exit. Fix the acceptance criteria in writing, including the performance thresholds and a crawl of the staging site with zero broken internal links and correct canonical tags. Agree a defect period after launch during which fixes are included. And be clear about what is not in scope, since content production, product data cleanup and photography are frequently assumed by the buyer and excluded by the builder. Stores that go on to hire an e-commerce marketing company usually discover the build decisions above were the constraint all along, which is the argument for getting them right while the site is still being made.
Questions people ask about e-commerce website development
Custom build or an established platform?
For most catalogues, an established platform with careful configuration beats a custom build, because the search, payment and security fundamentals are already solved and maintained. Custom work earns its cost when the business logic is genuinely unusual. Ask a candidate to argue against their own recommendation and see how good the counter-argument is.
How do we stop filters from creating thousands of URLs?
Decide during the build which facet combinations should be crawlable and linkable, and which should be handled without generating indexable URLs. Google's ecommerce documentation covers faceted navigation directly. Retrofitting this after launch means undoing crawl waste that has already been discovered.
What performance target should we write into the contract?
Use the Core Web Vitals thresholds as acceptance criteria on your key templates: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or below 0.1, at the 75th percentile of real loads. Measuring on mid-range mobile hardware, not a fast laptop, is what makes the target meaningful.
When should redirects be built?
Before launch, tested on staging, covering every existing indexed URL rather than just the top pages. Use permanent server-side redirects, keep them in place for the long term, and monitor crawl errors daily for several weeks after switchover so anything missed is caught while the traffic loss is still recoverable.