The Modules Every New PrestaShop Store Should Install First

Most "essential modules" lists tell you what to install. This one is about when — specifically, why a handful of modules belong on a PrestaShop store on day one, before the first product and the first customer, and why installing the exact same modules six months later costs you real work instead of ten minutes. A fresh PrestaShop install is functional but deliberately unfinished: the SEO is bare, the checkout is stepped, the back office has no real analytics, and product URLs carry numeric IDs. None of that is a bug. PrestaShop ships a foundation and expects modules to do the finishing. The catch is that a few of those finishing decisions get baked into your data the moment you start adding products and taking orders — and unbaking them later is the expensive part.

So this is not a "must-have list" (we keep a broader one over at essential PrestaShop modules: the must-have list) and it is not an argument about quantity (that's why module quality matters more than quantity). It's a sequencing guide: the short list of modules whose value is destroyed by installing them late, in the order a new store should add them.

The principle: some module choices are retroactive, most aren't

The reason order matters comes down to a single distinction. A module that changes how a page renders can be added anytime — a chat widget, a related-products block, a wishlist. Nothing in your database depends on it; install it whenever you're ready. But a module that changes how data is generated — the URL written into every product, the canonical tag Google indexes, the field structure of your customer records, the numbering of your invoices, the analytics history you accumulate — only helps the records created after you install it. Everything created before keeps its old shape, and converting it means migrations, redirects, or back-filling.

That's the whole framework. Before you add the first product or take the first order, install the things that shape generated data. Defer everything that only shapes presentation. The list below is sorted by that logic, not by perceived importance.

1. URL structure — before a single product exists

PrestaShop's default friendly URLs still embed the product ID (/123-product-name) and, worse, generate a different URL for the same product depending on which category path the visitor arrived through — a classic duplicate-content source. You set the pattern under Shop Parameters → Traffic & SEO → Set up URLs, but the route schema and per-product canonical behaviour are where the default falls short.

This is the single most order-sensitive choice on the list. Every product you add inherits its URL the instant you save it. Change the URL scheme after Google has indexed a few hundred pages and you owe a 301 redirect for every affected page, plus a ranking wobble while search engines re-crawl and re-attribute authority to the new addresses. Our Friendly URL module strips the numeric IDs, enforces one canonical URL per product no matter how many categories it sits in, and locks the pattern down before any of that history exists. So what? You never run a redirect-mapping project — because there was never a wrong URL to redirect from.

2. Technical SEO foundation — also before products

The other half of the SEO foundation is structured data, meta-tag templating, canonicals and sitemap rules — the things that decide whether your pages earn rich snippets and how cleanly they're indexed. PrestaShop's defaults cover the bare minimum (a sitemap if you enable one, basic meta fields you fill in by hand per product). SEO Revolution adds the parts the core leaves out: Product/Offer/Breadcrumb structured data, bulk meta-tag templates so you're not hand-writing 400 descriptions, canonical control, and redirect management in one place.

Why before products and not after? Because meta-tag templates only auto-populate the products created while the template is active. Add the module after the catalogue is in and you're back-filling metadata by hand — exactly the manual job the templating exists to avoid. SEO authority also compounds: a store that ships correct structured data and canonicals from page one accrues it from day one, rather than waiting six months and then asking Google to re-evaluate everything. We make the broader case for treating this as foundation, not decoration, in lessons from 10 years of PrestaShop development.

3. Invoice numbering — before the first order

Your very first completed order generates an invoice, and PrestaShop assigns invoice numbers sequentially and irreversibly. If your accountant needs a prefix, a yearly reset, a specific format, or legal fields the default template omits, you have to fix it before order number one — because you cannot renumber issued invoices. Sort it out after you've shipped 500 orders and you're choosing between a confusing mid-year numbering break and a conversation with your tax advisor.

The relevant native settings live under Orders → Invoices (invoice prefix, number, legal free text), but they're thin. Invoice Number gives you proper control over numbering schemes, formats and content from the first invoice onward. So what? Your books are correct from order one, and you never have to explain a numbering discontinuity to anyone.

4. Customer registration fields — before registrations open

If your business needs data at signup — a VAT number for B2B, a company name, a phone preference, "how did you hear about us" — the time to add those fields is before the first customer creates an account. PrestaShop's default registration form is fixed; adding fields later means the field exists but every existing customer record has it empty, and the only way to fill the gap is to email people and ask. Customer Registration Fields adds the custom fields up front, so the data arrives complete and you're never running a back-fill campaign against your own database.

5. Analytics — before any traffic

This one isn't about your database, it's about a history you can never recreate. Analytics data is not retroactive: a day without Google Analytics 4 or Search Console connected is a day of measurement you can't get back, even if the store had ten visitors. Connect both before launch — even pre-promotion — so you have a genuine baseline to measure every later change against. PrestaShop has no native GA4 integration worth the name; wire it in early and your first marketing push is measurable from the first click rather than from "whenever we remembered to add the tag."

6. Checkout — before the first customer, but for a different reason

Checkout earns its day-one slot on a slightly different logic. The default PrestaShop 1.7+ checkout is a single URL that reveals itself one gate at a time — personal info, then addresses, then delivery, then payment — and each gate is a place orders quietly leak. The cost of installing a checkout module late isn't a data migration; it's every order you lost to the stepped flow in the meantime, which you can't recover. Checkout Revolution collapses those gates into a true one-page flow from the back office, without theme surgery or core edits, so it survives upgrades. (Native checkout improvements are being discussed and developed, but current production stores still commonly need a checkout module for a true one-page flow — so for any store shipping now, the stepped checkout is still the default.) We go deep on the mechanics — and why the native checkout stops short — in the one-page checkout guide. Install it before you open to customers and the leak never starts.

The day-one sequence, in order

Putting it together, here's the order for a brand-new store — and crucially, what breaks if you wait, because that's the whole reason the sequence exists:

What deliberately isn't on this list

Notice what's missing: chat widgets, social blocks, loyalty programs, related-product carousels, A/B testing, marketing automation. They're absent not because they're unimportant, but because none of them is order-sensitive — a chat widget added in month six works exactly as well as one added on day one, and a loyalty program is pointless until you have repeat customers to reward. Installing them on a zero-traffic store adds surface area and configuration with no offsetting benefit. They belong on the broader must-have list, added when the store actually needs them — not on the day-one foundation.

And resist the urge to install everything at once for the comfort of feeling prepared. Every module is code that runs on every page load; a lean foundation is faster and easier to debug than a kitchen-sink install you assembled before you understood your own requirements. If you're tempted to grab a pile of free modules to cover the gaps, read the real cost of free modules first — "free" frequently means abandonment, no support, and a security liability you inherit.

The point

Starting a PrestaShop store right takes roughly the same effort as starting it wrong — the difference is entirely in when you make a few specific decisions. Install the data-shaping modules (URLs, SEO, invoicing, registration fields, analytics, checkout) before the data they shape exists, and you skip every corrective migration that catches up with stores that bolt them on later. Everything else can wait for the day your store is ready for it. The foundation isn't about having the most modules on day one. It's about having the right few in place before they become impossible to add cheaply.