What an ecommerce site has to get right before anything else
Ecommerce website design is work on three things: a catalog, a cart and a checkout. Everything else on the site is arranged around those three.
The interesting part is what that arrangement does to the numbers, because a store reports on itself every single day. A brochure site can be mediocre for years and nobody finds out, because no number is attached to it and everybody agrees it looks nice. A store cannot do that. There is a conversion rate, there are abandoned carts, there is a revenue figure per session, and every one of those numbers is a verdict on decisions somebody made about the product page and the checkout. Ecommerce website design is the discipline of making those numbers go up – and most of it happens in places that never appear in a design mockup.
That is why we start an ecommerce project with the catalog rather than the homepage. The homepage of a store gets a smaller share of the traffic than anybody expects; the pages that carry the business are the category pages and the product pages, and those are templates rather than compositions. Get the template right and you have improved four hundred pages at once. That is the leverage. Get it wrong and you have made the same mistake four hundred times.
We build stores on WooCommerce and on Shopify, we will tell you which one your business actually needs, and sometimes the answer is the one we make less money on.
There are six jobs a store does, and a store that does five of them well is still a store that is losing money on the sixth.
It has to be findable, which is search – and that is the slowest part of the whole thing. It has to make the product understandable, which is photography, copy and specifications. It has to make the product believable, which is reviews, returns policy and the small signals that tell a stranger you are real. It has to be fast, because every second of load time on a phone on rural signal is a percentage of people who never see the product at all. It has to take money without friction, which is the checkout. And it has to keep the customer, which is email and the second order.
Almost every store we look at is strong on the first two, weak on the third – and has never had anybody measure the fourth. The checkout is usually whatever the platform shipped by default. The sixth job is often nobody’s.
None of that is exotic. It is just work, spread over six areas, and design agencies tend to do the two that photograph well.
WooCommerce versus Shopify, honestly
This is the first real decision and it gets made badly more often than anything else in ecommerce web design, usually because the person answering it only builds one of the two.
Shopify is a hosted platform. You pay monthly, they handle the servers, the PCI compliance, the checkout and the updates, and you build inside the boundaries they set. WooCommerce is a plugin that turns WordPress into a store. You own everything, you host it yourself, there is no revenue share, and the flexibility is close to unlimited because there is nothing stopping you. Those two sentences contain the entire trade – and everything else is detail.
The dishonest version of this comparison is the one where an agency tells you their platform wins on every axis. Neither one does. Shopify’s checkout is better than almost anything you can build – and it is also a checkout you do not control. WooCommerce gives you total control of the content layer, and it hands you the hosting, security and performance that Shopify was quietly doing for you.
So the question worth asking is which set of problems you would rather own, because both sets are real and you are choosing between them rather than escaping them.
When Shopify is the right answer, and we will say so
We will tell a client to go to Shopify, and we have – and it costs us the bigger build fee every time.
Shopify is the right answer when the store is the business rather than a part of it, when the catalog is large and changes constantly, and when there is a warehouse with real fulfillment volume behind it. It is the right answer when nobody on the client’s side wants to think about hosting, backups or plugin updates ever again, and when the peace of mind is worth the monthly fee and the transaction cut. It is the right answer when you are selling into multiple countries and currencies, because doing that properly on WooCommerce is real work and Shopify has already done it.
It is also the right answer when the business has no technical person and no appetite for a maintenance relationship. A WooCommerce store with nobody maintaining it is a liability with a shopping cart attached; a Shopify store with nobody maintaining it just keeps working, and that difference is worth money to the right owner.
What Shopify costs you is control of the checkout, a percentage on transactions unless you use their payments, apps that, on the stores we have looked at, stack up at fifteen to fifty dollars a month each until the “cheap” platform is costing three hundred a month, and a content layer that is decent rather than excellent. That last one matters more than most people realize, and it is the reason the next section exists.
When WooCommerce wins
WooCommerce wins when content is doing the selling. That is the whole test.
If your store’s growth is going to come from search, from long product education, from a blog that actually earns traffic, from landing pages built to match campaigns and from a site that is half store and half publication, WordPress is a better home and it is not close. The content tools are better, the URL structure is yours to design, the templating is unrestricted, and the SEO work has fewer walls in it. A winery with a club, a tasting room, an events calendar and a shop is a WordPress site with commerce inside it rather than a store with a blog bolted on, which is most of why our wine marketing work lives there.
It also wins on ownership, which sounds like ideology – and turns into money. No revenue share, no platform that can change its terms, no app subscriptions stacking up, and your data is in a database you control. Clients own their code, content and data outright, and with a hosted platform you own considerably less of that than you think.
The costs are real and we say them out loud. All of them. You need hosting that is genuinely good rather than the cheapest available. You need somebody applying updates on staging rather than at random. You need a person who is accountable when the checkout breaks at nine at night. If nobody in this arrangement is going to do those things, take the Shopify option and sleep well.
We build WooCommerce as a hand-coded block theme with no page builder, which is the difference between a store that loads in under two seconds and a store that ships four hundred kilobytes of JavaScript to show a product image. The technical detail sits on WooCommerce SEO.
The product page, and the order things go in
The product page is where the money is decided and it is the most copied and least considered template on any store.
The order matters more than the styling. It always has. Image first and large, because people buy with their eyes and the first photograph does more work than any paragraph on the page. Then the product name and the price, visible without scrolling, because a hidden price reads as a trick. Then the variant selection, which is where an alarming number of stores lose people by making size or color a dropdown that does not show what is unavailable until after you pick it. Then the add-to-cart button, which should be the most obvious thing on the screen – and frequently is not.
Below that is the part that decides the sale for anybody who is thinking rather than impulse buying. The full description written for a human rather than for a keyword. The specifications as a table, because people scan tables and skip paragraphs. Shipping cost and delivery timing stated on the product page rather than discovered in the checkout, which kills more carts than anything else we see. The returns policy in a sentence. Reviews from real buyers. Stock status that is honest, including the products you have run out of.
Then the related products, which is the slot we would look at first if a store asked us where its average order value was hiding, and which most stores fill with whatever the platform picked at random.
What we do not put on a product page
No carousel of the same product photographed five times where the customer has to hunt for the one that shows the back. No accordion hiding the description behind a click, because content nobody expands is content nobody reads and it also does nothing for search. No countdown timer, no fake scarcity, no “eleven people are viewing this.” Those tricks work on strangers once and they cost you the customer who was going to buy from you for a decade.
Product photography, which we cannot design our way around
The best ecommerce website design in the world cannot rescue bad product photography, and this is the conversation nobody wants to have at kickoff.
A store’s images are its product. On a screen, the photograph is the only sensory information a customer gets, and a set of images taken on a phone against a cluttered counter tells the customer something about the business that no amount of typography will undo. Consistent background, consistent lighting, consistent crop across the whole catalog – the set has to look like one set. Multiple angles including the one nobody photographs, which is the back or the underside or the bit that people actually ask about. Something in frame for scale. A photograph of the product in use by a person, because that is the one that sells.
We build the site to handle images properly, which means serving modern formats at the size they display, generating the right variants automatically, and lazy loading below the fold without breaking the largest contentful paint at the top. What we cannot do is invent photographs that do not exist. Budget for the shoot. It is the highest-return line item on the whole project – and it is the first one people cut.
Category pages are the pages that actually rank
Here is the thing that surprises most store owners: your category pages, not your product pages, are usually where organic traffic comes from.
Somebody searching “leather work boots” is not looking for one specific product, they are looking for a set of options, and Google knows that and serves category pages accordingly. Individual product pages rank for the brand and model number of the thing, which is a small pool of searches – and often one your suppliers are competing with you for anyway. The commercial searches with real volume behind them land on categories.
Which means the category page cannot be a grid of thumbnails and nothing else. It needs a real H1, an introduction that explains what is in this category and how to choose between the options, and ideally a section further down that answers the questions a buyer has at this stage. Not four hundred words of keyword filler above the products, which pushes the products below the fold and annoys the customer to please a crawler. A short, useful lead-in above and the substantial content below the grid.
The other half of category work is the hierarchy itself. Categories that reflect how customers search rather than how your warehouse is organized, one canonical home for every product rather than the same item living in six categories with six URLs, and a breadcrumb trail that makes the structure legible to a human and to a crawler at the same time.
Site search, and what people type into your store
Internal search is the most under-read report in ecommerce and it is a transcript of your customers telling you what they want.
People who use site search convert at a much higher rate than people who browse – somebody typing a product name has already decided. That means the search box deserves to be visible rather than hidden behind a magnifying glass icon on mobile, and it means the results need to be good: tolerant of typos, matching on synonyms and part numbers, showing images in the results, and never returning an empty page with no suggested alternative.
The report is the real prize. Every week your customers type things into that box, and the searches that return nothing are a list of products you should stock, categories you have named wrong, or terms your industry uses that your website does not. We set the search log up on every store we build and we read it in the first month, and it has changed the category structure more than once.
The cart and the checkout, where the money leaks
Something close to seven in ten carts are abandoned across the industry, and while some of that is browsing behavior that nothing will fix, a large slice of it is self-inflicted.
The reasons are consistent and they are boring. Shipping is usually first. Shipping cost revealed at the last step. A forced account creation before checkout. Too many form fields. No visible progress. A payment method the customer wanted and you did not offer. A checkout that breaks on a phone. Nothing about that list requires research to fix, and almost every store we look at is doing at least two of them.
What we build instead: shipping cost visible early and ideally on the product page, guest checkout offered first with account creation as an option afterward, one page or clearly stepped, address autocomplete, real-time validation that tells you about the problem next to the field instead of after you submit, and a cart that persists so somebody can come back on a laptop and finish what they started on a phone.
Then there is trust, which is not decoration – it is infrastructure. The security signals, the returns policy, the contact information, a phone number that works. On a store nobody has heard of, in a small market, a real address in Walla Walla and a phone that a human answers is worth more than any badge.
Abandoned cart recovery
The highest-return automation we put on a store is an email to somebody who left something in the cart, and it is usually the last thing anybody sets up. Three messages over a few days, the first one helpful rather than pushy, is standard practice for a reason. We wire it up at launch instead of adding it in month six.
Payments, and what actually needs to be there
Payment choice is a conversion feature – and store owners tend to think of it as an accounting decision.
The floor is cards processed cleanly, which for our builds usually means Stripe or Square, and then the wallets, because Apple Pay and Google Pay turn a checkout on a phone into a thumbprint and remove every form field at once. If a meaningful share of your traffic is mobile, and it is, wallet payments are not a nice extra. PayPal still matters to a demographic that will simply leave without it. Buy-now-pay-later belongs on stores with a high average order value and nowhere else.
The compliance conversation is short and worth having. If the payment fields live on your own server you inherit a much heavier PCI burden than if the processor hosts them, which is why we keep card entry inside the processor’s own frame on WooCommerce builds. Shopify handles this for you and charges you for the privilege, and depending on your volume that is either a bargain or an expensive convenience.
Shipping, tax and the parts that decide whether the store is worth running
Shipping is where ecommerce projects go quietly wrong – because it is a business decision that everybody treats as a settings screen.
You need to decide, before anybody builds anything, whether you are doing flat rate, free shipping over a threshold, live carrier rates, or local pickup. Each one changes the checkout and each one changes the margin. Free shipping over a threshold is the strongest conversion lever of the four and it only works if the threshold is set against your actual average order value rather than a number that sounded good. Live rates from USPS or UPS are honest and they add a step and a delay. Local pickup matters more than people think in a town like ours, where half the customers are within ten minutes of the door.
Then the operations. Somebody has to pick, pack and post the orders, and a store that sells forty items a day and has no fulfillment plan is a business with a new problem rather than a new revenue stream. ShipStation or similar, labels printed properly, tracking sent automatically. Sales tax is handled by an automated service now and that is the correct answer; nobody should be maintaining tax tables by hand in 2026.
We ask these questions in week one, and the answers change the build. That is why they are not left to the end.
Selling the same stock in a shop and online
Plenty of stores around here have a counter as well as a website, and the moment both are selling the same item you have an inventory problem rather than a web design problem.
The failure is easy to picture. Somebody buys the last one at the counter on a Saturday afternoon, the website never hears about it, and on Sunday morning an order arrives online for a thing that no longer exists. Now you are writing the apology, refunding a card and hoping the customer takes it well. That is not a rare edge case; for a shop with a small catalog and a busy till it is a monthly event, and it costs a young store more goodwill than a slow product page ever will.
There are three honest answers and they cost very different amounts. The first is to keep the two catalogs genuinely separate, so the website sells a subset the counter never touches – the cheapest fix, and the right one for most small shops. The second is to run the till and the store on one system, which Shopify does well with its own hardware and which WooCommerce does through a connector somebody has to watch. The third is a nightly sync out of whatever inventory system the business already runs, which is fine for slow-moving stock and genuinely dangerous for anything that sells out in an afternoon.
We ask which one you want in week one, because the answer changes the build and it can change the platform recommendation. A tasting room releasing library wines to a club, a deli selling the shelf-stable goods it also stacks by the door, and a boutique holding one of everything are three different problems wearing the same shopping cart.
The related decision is what the site does when something runs out, and hiding the product is the worst of the available options, because the URL dies, the ranking it earned dies with it, and the customer who searched for that exact thing lands on a 404. Keep the page. Mark it out of stock honestly, offer a notify-me capture, and you have kept the ranking and gained a demand signal for the next order. Local pickup deserves the same plain treatment; if somebody in Walla Walla can have it today by driving four minutes, that belongs on the product page rather than at the end of the checkout.
Product schema, rich results and the Merchant Center
Structured data is how you tell Google what a product page is instead of hoping it works it out, and on a store it is not optional.
Product schema carries the name, the price, the currency, the availability, the identifiers and the aggregate rating, and when it is correct the search result shows the price and the stock status and the stars. That is a bigger click-through difference than most on-page changes will ever produce. It also feeds the free listings in Google Merchant Center, which is a genuinely useful channel that plenty of small stores never switch on.
The parts that go wrong are consistent. We see the same four. Prices in the markup that do not match the prices on the page, which Google penalizes by dropping the enhancement entirely. Review markup for reviews that do not exist, which is a manual action waiting to happen. Availability that never updates because the schema was hard-coded at build. Missing GTIN or MPN identifiers on products that have them, which quietly limits what Google will do with the listing.
We generate the markup from the actual product data so it cannot drift, and we validate it. Then we watch the enhancement reports in Search Console for the first month, because a schema error at scale is a schema error on every product you sell.
Site speed when there is a real catalog behind it
A store is slower than a brochure site by nature, and that is exactly why the build method matters more here than anywhere else.
Every product page runs database queries, session handling, cart state and often a stack of third-party scripts, and none of that can be cached as simply as a static page. Add a page builder on top and you have a product template shipping an enormous payload to show a photograph, a price and a button. This is the part of ecommerce web design where our position is unfashionable and unmovable: hand-coded block theme, no Elementor, no page builder, and every script justified before it goes in.
What that means in practice is object caching and full-page caching configured for a store rather than for a blog, so the cart and the checkout stay dynamic while the catalog is served fast. Images in modern formats at display size, which on a catalog of a thousand products is an automated pipeline rather than a person. A CDN in front of it. Third-party tags on a budget, because the chat widget, the review widget, the two analytics tools and the pixel are each a decision and collectively they are the reason your store is slow. Core Web Vitals measured on a phone on a real connection, not on a laptop in the office.
Speed is a ranking factor – and everybody already knows that. The bigger deal is that it is a conversion factor, and on a store you can watch the revenue move.
Online store design on a phone, which is where the traffic is
Most stores we look at now take most of their traffic on phones, and a good share are still designed on a twenty-seven inch monitor.
The differences are not cosmetic. They are structural. A filter panel that sits in a sidebar on a desktop has to become something that opens, applies and closes on a phone without losing your place in the grid. Product images need to be swipeable and zoomable without hijacking the page scroll. Tap targets have to be big enough for a thumb. The add-to-cart button should stay reachable as somebody reads down a long product page, because scrolling back up to buy is friction nobody needs.
The test we use is the actual site, on an actual phone, held one-handed, on a connection that is not office wifi. A browser window dragged narrow on a desktop catches almost none of it. Half the problems only appear that way – and they are the expensive half.
Accessibility, which is a floor and not a feature
Ecommerce accessibility is where the legal exposure in web design actually sits, and small stores tend to find that out from a demand letter.
The practical work is unglamorous and mostly free at build time: real alt text on product images that describes the product, form fields with proper labels rather than placeholder text doing the job, keyboard operation through the entire purchase path including the filters and the checkout, color contrast that survives on a phone in daylight, focus states you can see, and error messages that a screen reader announces. Nothing on that list makes the site uglier. Not one item.
We build to WCAG AA as the default rather than as an upgrade, because retrofitting accessibility into a finished store costs several times what including it costs, and because the overlay widgets sold as a one-line fix do not work and have themselves been the subject of litigation.
Migrating an existing store without losing the year
Replatforming a store is the riskiest thing we take on in this category, and it is also the reason people call us more often than any other.
Four things have to move – and each one breaks differently. The products, with their variants, images, descriptions and SKUs intact. The customers, with their accounts and their addresses and without their passwords, which do not transfer and require a reset flow that has to be communicated properly. The orders, because your history is your business and a store with no order history cannot answer a support question. And the URLs, which is where the traffic lives.
That last one is the same discipline as any website redesign and it is more brutal on a store, because a store has thousands of URLs rather than dozens. Every product, every category, every filtered page that earned a ranking needs a mapped destination on the new platform. Bulk-redirecting a product catalog to the new homepage is a deletion with extra steps, and it is done more often than anyone would guess.
We migrate onto staging, reconcile the numbers against the old store product by product, test the checkout end to end with real cards, and only then point the domain. The reconciliation is the part clients are surprised by, and it is where we catch the two hundred products whose variants did not come across cleanly.
Launch, and the first month where the data arrives
A store launch is not finished when the site goes live; it is finished when the first month of data says it is working.
The tracking has to be right before launch rather than after, and on a store that means ecommerce events firing correctly for product views, add to cart, checkout steps and purchases, with revenue figures that reconcile against what the payment processor says. If those two numbers disagree, every decision you make for the next year is made on fiction. We check them against each other in week one.
Then we watch the funnel, which on a new store almost always has one step that is much worse than the others. Sometimes it is a shipping surprise. Sometimes it is a payment method missing. Once it was a required field nobody could complete on an iPhone. You do not find those in a design review, you find them in the data, and the first month is when they are cheap to fix.
What happens after the first order
The customer we would rather see a store spend its next hour on is the one who already bought something, and the small stores we look at spend almost all of theirs chasing the other kind.
Email is the channel that still belongs to you, and it needs to exist at launch rather than being deferred. The welcome sequence, the abandoned cart flow, the post-purchase message that arrives when the product does, and the review request timed to when somebody has actually used the thing. Klaviyo or similar, wired into the store so the segments are real. Reviews then feed the product pages, which feed the schema, which feeds the search results, and the loop closes.
What ecommerce website design costs
The low end is a store with a manageable catalog, standard variants, one shipping model, standard payments, a custom block theme built on your existing brand, and content you supply. That project is a real store built properly and it is not a compromise; plenty of businesses in the Walla Walla Valley need exactly that and nothing more.
The middle is where most stores land. A larger catalog with complicated variants, a migration from an existing platform with its redirect map, custom category templates, faceted navigation designed rather than defaulted, subscriptions or a club, and integration with whatever fulfillment or inventory system the business already runs.
The high end is bespoke work: a product configurator, a wholesale portal with its own pricing, multi-currency, an ERP integration, or a catalog in the tens of thousands where performance and crawl management are engineering problems in their own right.
Shopify builds cost less on the build side and carry the platform fee and the transaction percentage forever. WooCommerce costs more up front and nothing per sale. Run that arithmetic against your own revenue over three years, because the answer flips at a volume that is easy to calculate and that nobody ever calculates.
How long an ecommerce build takes
Six to ten weeks for most stores – and the two things that stretch it are product data and photography.
Weeks one and two are discovery and structure: catalog architecture, category hierarchy, the shipping and tax decisions, the platform call, and the URL map if this is a migration. Weeks three and four are design of the templates that matter, which is the category page, the product page, the cart and the checkout, with the homepage designed after those rather than before. Weeks five through eight are build, integration and data migration on staging. The last two weeks are testing, which on a store means real transactions with real cards, real refunds, and every variant and shipping method exercised.
A catalog that arrives as a clean export lands at the short end. A catalog that lives in a spreadsheet with inconsistent SKUs and photographs that have not been taken yet does not, and no amount of project management fixes that. We will tell you which one you have in week one, and we will tell you plainly.
Common questions
Should I use WooCommerce or Shopify?
Shopify if the store is the whole business, the catalog is large and changing, and you never want to think about hosting or updates. WooCommerce if content and search are going to drive your growth, you want full ownership with no transaction cut, and you have somebody maintaining it. We make the call on your catalog and your volume, not on which one we prefer to build.
How long does it take to build an online store?
Six to ten weeks in most cases. The variable is almost never the design; it is how clean your product data is and whether the photography exists yet.
Will my new store rank on Google?
Category pages carry most of the organic opportunity and product pages carry the branded and model-number searches. A new store takes three to six months to become visible and nine to twelve to be worth what you paid, and no build alone gets you there without content behind it.
What is faceted navigation and why does it matter?
It is the filter system on your category pages, and left unmanaged it generates thousands of crawlable near-duplicate URLs that waste crawl budget and dilute your real pages. The fix is deciding per filter which combinations deserve an indexable page and blocking the rest.
Can my website and my shop counter share the same stock?
They can, and the three routes are a separate online catalog the counter never touches, a single system running both the till and the store, or a nightly sync out of your existing inventory software. The first is cheapest and the safest for a small shop, and the third is the one that oversells a fast-moving item. We decide that in week one, because it changes the platform call.
Can you move my store off Shopify or Squarespace?
Yes, and the work is products, customers, order history and URLs, in roughly that order of difficulty. The URL map is the part that protects your traffic and it is the part most migrations skip.
Do I need product photography before we start?
You need it before launch, and having it early makes every design decision better. It is the highest-return spend on the project and the one most often cut.