Instant Redis

OPcache is a PHP extension that caches compiled PHP code in memory, so PHP does not have to recompile it on every request. You should absolutely enable it — it can improve PrestaShop performance by 30-50% with zero downsides for production. Most hosting providers have it enabled by default. The important setting is opcache.validate_timestamps: set to 1 on development, but many production servers set it to 0 for maximum performance (which means you need to manually reset OPcache after deploying code changes).

See our full guide on PHP optimization

Generally yes — CCC combines multiple CSS files into one and multiple JS files into one, reducing HTTP requests and improving load times. However, CCC can cause issues if a module's CSS/JS has specific loading order requirements or uses defer/async attributes. If you enable CCC and something breaks (usually a visual glitch or a JS error), check which module's assets are causing the problem and configure that module to keep its assets separate.

Learn more about CSS/JS optimization

Free performance wins: (1) Enable OPcache in PHP (massive impact, zero cost). (2) Enable PrestaShop's Smarty cache and CCC (Combine, Compress, Cache). (3) Disable unused modules — each active module adds overhead even if it does not output anything visible. (4) Optimise your images before uploading (use tinypng.com or similar). (5) Enable MySQL query cache. (6) Make sure you are not running in debug mode. These alone can double your page speed.

See our real-world PageSpeed 99 case study

Disabling cache entirely will make your store noticeably slower. Instead, clear the cache properly: Advanced Parameters → Performance → Clear cache. If problems persist after clearing: delete the contents of /var/cache/prod/ and /var/cache/dev/ manually. For Smarty cache: check if "Force compile" is set to "Yes" (it should be "No" in production). If a specific module misbehaves with cache, report it to the module developer — it is a bug that should be fixed.

Understand PrestaShop caching in depth

Use your browser's Developer Tools (F12 → Network tab) to identify what is slow. Common causes: (1) A module loading heavy external scripts (fonts, analytics, chat widgets). (2) A module making slow database queries — check the Symfony profiler bar in debug mode. (3) Too many modules registered on the same hook (e.g., displayHeader). (4) OPcache disabled on the server. (5) Hosting resources maxed out. Disable modules one by one to identify the culprit.

See how we achieved PageSpeed 99 with 80+ modules

Both work well. PrestaShop officially supports MySQL 5.7+ and MariaDB 10.x+. MariaDB is often slightly faster for read-heavy workloads (which e-commerce stores tend to be). Most hosting providers offer one or the other. If you have a choice, MariaDB 10.11 LTS is a solid option. The performance difference is minimal for most stores — focus on proper indexing and query optimisation rather than the database engine choice.

Read about database optimization for PrestaShop

PrestaShop itself runs fine with 256MB PHP memory limit for most stores. However, if you have many modules installed, large product catalogs, or run import/export operations, you may need 512MB or more. The server itself should have at least 2GB RAM for a small store, 4GB+ for medium stores with caching enabled. These are minimums — more is always better.

Read our performance tuning recommendations

Go to Advanced Parameters → Performance and click "Clear cache". This clears Smarty compiled templates and Symfony cache. For a more thorough clear: also delete the contents of /var/cache/ manually (both prod and dev folders). If you are using OPcache, you may also need to restart PHP-FPM or Apache to clear the opcode cache. Simply clearing the PrestaShop cache does not clear OPcache.

Learn about caching strategies for PrestaShop

How PrestaShop Email Templates Work

PrestaShop sends transactional emails at every key point in the customer journey: account creation, order confirmation, shipping notification, password reset, and more. These emails are generated from template files stored on your server, and they are fully customizable. Understanding how the template system works is the first step toward creating professional, branded order confirmation emails that reinforce your store's identity.

Every PrestaShop email consists of two template files: an HTML version for email clients that support rich formatting, and a plain text (TXT) version for email clients that do not. Both files must exist for an email to send correctly. The HTML version is what the vast majority of your customers will see. The TXT version serves as a fallback and is also used by accessibility tools and some corporate email filters.

Email templates live in the mails/ directory structure. The exact location depends on whether you are using core emails, theme-overridden emails, or module-specific emails. Understanding this hierarchy is essential because PrestaShop checks multiple locations for each template and uses the first one it finds.

The Email Template Directory Structure

PrestaShop organizes email templates in a specific directory hierarchy. When it needs to send an email, it searches these locations in order of priority:

Theme-Level Overrides (Highest Priority)

Templates in /themes/your-theme/mails/en/ (where en is the language ISO code) take priority over all other locations. If you want to customize an email template without modifying core files, this is where your custom templates should go. This approach survives PrestaShop updates because theme files are not overwritten during core updates.

Core Templates (Default)

The default templates live in /mails/en/ in your PrestaShop root directory. These are the templates that ship with PrestaShop and are used when no theme override exists. Editing these files directly works but is not recommended because your changes will be lost when you update PrestaShop.

Module-Specific Templates

Modules that send their own emails store templates in /modules/module-name/mails/en/. For example, the order notification emails sent by the core payment modules are stored in their respective module directories. You can override these by placing modified copies in your theme's mails/ directory with the same filename.

Language Subdirectories

Each mails/ directory contains subdirectories for each installed language, using the language ISO code: en for English, fr for French, de for German, and so on. When PrestaShop sends an email, it uses the template from the directory matching the customer's language preference. If a template does not exist in the customer's language, PrestaShop falls back to the default language.

Anatomy of an Order Confirmation Template

The order confirmation email is the most important transactional email your store sends. It is the file named order_conf.html (and its companion order_conf.txt) in your mails directory. Let us examine its structure.

HTML Template Structure

PrestaShop email templates are standalone HTML documents. They do not use external CSS files because most email clients strip external stylesheets. All styling must be inline CSS. A typical order confirmation template includes these sections:

The document starts with a standard HTML doctype and head section. The body contains a table-based layout (because email clients have poor support for modern CSS layout methods like flexbox and grid). Within this layout, you find a header section with your store logo, the main content area with order details, a product table listing each item ordered, pricing summary with subtotals and totals, shipping information, payment method details, and a footer with store contact information and legal notices.

The Variable System

PrestaShop uses a simple variable replacement system in email templates. Variables are enclosed in curly braces: {variable_name}. When the email is generated, PrestaShop replaces each variable with its actual value. The order confirmation template uses these key variables:

{firstname} and {lastname} contain the customer's name. {order_name} is the order reference number (like ABCDEF123). {shop_name} is your store's name as configured in the back office. {shop_url} is your store's URL. {shop_logo} is the path to your store's logo image. {date} is the order date. {payment} is the payment method used. {total_paid} is the total amount paid. {delivery_company} and {delivery_address} contain shipping carrier and address information.

For the product list, PrestaShop uses a special block syntax. The product items section is wrapped in a loop that repeats for each product in the order: {items} contains the pre-formatted HTML for the entire product list table, including product names, quantities, prices, and any customization details.

Available Variables Reference

To see all available variables for a specific email template, look at the PHP code that sends the email. For order confirmation, check the PaymentModule class (in /classes/PaymentModule.php). The validateOrder() method builds the array of template variables. Each key in the array corresponds to a variable name you can use in the template.

Common variables available in order confirmation emails include: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message}, and {total_products}.

Customizing the Order Confirmation Template

Step 1: Create a Theme Override

Never edit the core template files directly. Instead, copy the template to your theme's mails directory:

Copy /mails/en/order_conf.html to /themes/your-theme/mails/en/order_conf.html. Do the same for order_conf.txt. If the mails/en/ directory does not exist in your theme, create it.

If your store supports multiple languages, copy the templates for each language directory. Your French order confirmation goes in /themes/your-theme/mails/fr/order_conf.html and so on.

Step 2: Modify the HTML Layout

Open the HTML template in a text editor (not a visual editor that might add unwanted code). Email HTML is different from web HTML in several important ways:

Use tables for layout, not divs. Email clients, especially Outlook, have very limited CSS support. A three-column layout must use a <table> with three <td> elements, not CSS columns or flexbox.

Use inline styles on every element. Instead of <p class="heading"> with a separate stylesheet, use <p style="font-size:18px; font-weight:bold; color:#333333;">. Every styled element needs its own inline style attribute.

Set explicit widths on tables and cells. Email clients do not always respect percentage-based widths. Use a fixed width for your main content table (600 pixels is the standard) with percentage-based internal columns.

Use web-safe fonts. Not all email clients support custom fonts. Stick to Arial, Helvetica, Georgia, Times New Roman, Verdana, or Trebuchet MS. You can try loading a custom font as a fallback, but always specify a web-safe font as the final fallback.

Step 3: Add Your Branding

Replace the default PrestaShop header with your store's branding. This typically involves updating the logo (the {shop_logo} variable automatically uses your store's logo, but you might want a specific email version), changing the header background color to match your brand, adding your brand's color scheme to headings and links, and including your store's tagline or a brief marketing message.

Keep the overall structure simple. Overly complex email designs break in different email clients. A clean, single-column layout with your brand colors and logo is more effective and more reliable than an elaborate multi-column design.

Step 4: Customize the Product Table

The default product table in PrestaShop's order confirmation is functional but basic. You can enhance it by adding product images (use absolute URLs to images hosted on your server, not relative paths), adding links to product pages so customers can easily reorder or leave reviews, adding custom fields like estimated delivery dates or personalized messages, and adjusting the table styling to match your brand.

When adding product images, keep them small (50 to 80 pixels wide) and always include an alt attribute. Some email clients block images by default, and the alt text ensures customers can still identify their products.

Adding Custom Fields to Order Emails

PrestaShop's default variables cover the standard order information, but you might want to include additional data like loyalty points earned, estimated delivery date, a personalized thank-you message, or cross-sell product recommendations.

Adding Variables via a Module

The cleanest way to add custom variables is through a module that hooks into the email sending process. Create a module that registers the actionEmailSendBefore hook (available in PrestaShop 1.7.6 and later) or the actionGetExtraMailTemplateVars hook. In your hook handler, add your custom variables to the template variables array:

Your hook function receives the template variables array by reference. You can add new variables to this array, and they become available in the template using the standard {variable_name} syntax. For example, after adding loyalty_points to the array in your hook, you can use {loyalty_points} in your order confirmation HTML template.

Using Existing Database Data

You can pull any data from your PrestaShop database into email variables. Common examples include the customer's total order count (to show "Thank you for your 5th order!"), the customer's loyalty point balance, custom product fields stored in product features or attributes, and warehouse or supplier information for the ordered products.

Multilingual Email Setup

If your store serves customers in multiple languages, every email template needs a version for each language. PrestaShop handles language selection automatically based on the customer's language preference, but you need to provide the templates.

Creating Language-Specific Templates

For each language your store supports, create a directory under your theme's mails folder: /themes/your-theme/mails/en/, /themes/your-theme/mails/fr/, /themes/your-theme/mails/de/, and so on. Copy and translate each template file into the appropriate directory.

Do not use automated translation for transactional emails. These emails represent your store's communication with customers, and poor translations damage trust. Have each language version written or reviewed by a native speaker.

Right-to-Left Language Support

If you support languages like Arabic or Hebrew, your email templates need RTL (right-to-left) layout support. Add dir="rtl" to the main table element and adjust text alignment and padding in your inline styles. Create separate templates for RTL languages rather than trying to make a single template work for both directions.

Date and Currency Formatting

PrestaShop automatically formats dates and currency values according to the customer's language and currency settings. The {date}, {total_paid}, and other formatted values already reflect the correct locale. However, if you add custom variables with dates or currency values, make sure to format them correctly for the target language.

SMTP Configuration for Reliable Delivery

The best email template in the world is useless if your emails do not reach the inbox. PrestaShop's default email configuration uses PHP's built-in mail() function, which is unreliable for transactional emails. Most of these emails end up in spam folders or are rejected entirely by modern email providers.

Why SMTP Matters

SMTP (Simple Mail Transfer Protocol) with proper authentication is essential for email deliverability. When you send email through PHP's mail() function, the email comes from your web server's IP address with no authentication. Email providers like Gmail, Outlook, and Yahoo see this as a red flag and often classify these emails as spam.

With SMTP, your emails are sent through an authenticated email server with proper SPF, DKIM, and DMARC records. This proves to receiving email servers that the email is legitimate and authorized by your domain.

Configuring SMTP in PrestaShop

Go to Advanced Parameters > E-mail in your PrestaShop back office. Change the method from "Use PHP's mail() function" to "Set my own SMTP parameters." Enter your SMTP server details: the server address, port (typically 587 for TLS or 465 for SSL), encryption type, username, and password.

Common SMTP providers for PrestaShop include Gmail SMTP (smtp.gmail.com, port 587, TLS, requires an App Password if 2FA is enabled), Amazon SES (affordable for high volume), SendGrid (generous free tier), Mailgun (developer-friendly with good logging), and your hosting provider's SMTP server (check with your host for settings).

Testing SMTP Configuration

After configuring SMTP, use the "Send a test email" button at the bottom of the email configuration page. Enter your own email address and check that the test email arrives in your inbox (not spam). If the test email fails, check your SMTP credentials, verify that your server can reach the SMTP server on the configured port (some hosting providers block outgoing port 25 and 587), and check if your SMTP provider requires specific security settings.

SPF, DKIM, and DMARC Records

For maximum deliverability, configure these DNS records for your domain. SPF (Sender Policy Framework) specifies which servers are authorized to send email on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a digital signature to your emails that proves they were sent by your domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do with emails that fail SPF or DKIM checks.

Your SMTP provider will give you the specific DNS records to add. For example, if you use SendGrid, they provide SPF and DKIM records during the domain authentication setup process. Add these as TXT records in your domain's DNS settings.

Testing Email Templates

Sending Test Emails

PrestaShop does not have a built-in way to preview specific email templates. To test your order confirmation template, you need to place a real test order. Create a test customer account, add products to the cart, and complete the checkout with a test payment method. If you have a sandbox payment module configured, use that. Otherwise, the bank wire or check payment methods let you complete an order without actual payment processing.

Testing Across Email Clients

Email rendering varies dramatically between email clients. What looks perfect in Gmail might be broken in Outlook. At minimum, test your templates in Gmail (web), Outlook (desktop and web), Apple Mail, Yahoo Mail, and at least one mobile email app. Services like Litmus or Email on Acid automate this testing by rendering your email in dozens of email clients simultaneously, but they are paid services.

Common Rendering Issues

If your email looks broken in Outlook, it is almost certainly a CSS issue. Outlook uses Microsoft Word's rendering engine for HTML emails, which has extremely limited CSS support. It does not support background images on table cells (use background colors instead), padding on block elements (use table cell padding), max-width (use fixed widths), margin for centering (use align="center" on tables), or CSS floats.

For mobile responsiveness, wrap your content table in a container with max-width:600px and add a media query in the head style block (which some email clients support) that sets table widths to 100% on small screens. This is not perfect responsive design, but it prevents horizontal scrolling on most mobile devices.

Common Issues and Troubleshooting

Missing Images in Emails

This is the most common email template problem. Images in emails must use absolute URLs (starting with https://), not relative paths. If your template references /img/logo.png, change it to https://www.yourdomain.com/img/logo.png. The {shop_logo} variable automatically generates an absolute URL, but any images you add manually must use full URLs.

Also verify that your images are accessible from outside your network. If your store is behind a firewall or HTTP authentication, email clients cannot load the images. Test by opening the image URL in a private/incognito browser window.

Broken Layout After Editing

Email HTML is fragile. A single unclosed tag or missing table cell can break the entire layout. Always validate your HTML after editing. Count your opening and closing table, tr, and td tags. Every <table> needs a </table>, every <tr> needs a </tr>, and every <td> needs a </td>. Check that every row in a table has the same number of cells (or uses colspan to make up the difference).

Variables Not Being Replaced

If you see literal {variable_name} text in your sent emails instead of actual values, check the variable name for typos. Variable names are case-sensitive. Also verify that the variable exists for the specific email type you are customizing. Not all variables are available in all email templates. The order-specific variables like {order_name} are only available in order-related emails.

Emails Not Sending at All

If emails are not being sent, check the PrestaShop back office under Advanced Parameters > E-mail. There you can see a log of sent emails. If the log shows failures, check your SMTP configuration. If no emails appear in the log, the email might not be triggered at all. Verify that your order status transitions are configured to send emails (Orders > Statuses > edit status > check "Send an email to the customer").

Also check your server's PHP error log for email-related errors. Common issues include PHP's mail() function being disabled by the hosting provider, SMTP authentication failures due to changed passwords, and network connectivity issues between your server and the SMTP server.

Emails Going to Spam

Even with proper SMTP configuration, emails can still land in spam. The most common reasons are missing or incorrect SPF/DKIM/DMARC records, email content that triggers spam filters (excessive use of capital letters, spam trigger words like "free" or "act now", too many images with little text), sending from an IP address with a poor reputation (common with shared hosting), and the "from" email address domain not matching the SMTP server domain.

Fix the DNS records first, then review your email content. Use a tool like mail-tester.com to analyze your emails for spam triggers. Send a test email to the address they provide, and they return a detailed report showing what might cause spam classification.

Theme-Specific Email Overrides

Some PrestaShop themes include their own email templates that match the theme's design. If your theme has templates in /themes/your-theme/mails/, these override the core templates automatically.

Checking for Theme Email Templates

Look in your active theme's directory for a mails folder. If it exists, the theme provides custom email templates. These templates usually match the theme's color scheme and header/footer design, giving your emails visual consistency with your storefront.

Customizing Theme Email Templates

If your theme provides email templates, edit those instead of copying from the core mails/ directory. The theme templates may use a different HTML structure or include additional CSS that is specific to the theme's design system. Starting from the theme's version ensures visual consistency.

Keeping Templates in Sync with Theme Updates

When you update your theme, check whether the update includes changes to email templates. If it does, your customizations might be overwritten. Before updating, back up your customized templates. After updating, compare the new templates with your backups and reapply your customizations to the updated versions. This is tedious but necessary to maintain both your customizations and any improvements or fixes the theme developer has made.

Best Practices for Order Confirmation Emails

A well-crafted order confirmation email does more than confirm the transaction. It builds trust, reduces support inquiries, and creates opportunities for engagement.

Include a clear order reference number prominently at the top. Customers need this number when contacting support or tracking their order. List every product with its name, quantity, price, and any options or customizations. Include the complete breakdown of subtotal, shipping cost, taxes, discounts, and total. Show the delivery address so customers can verify it and contact you immediately if it is wrong. Include the payment method used and any relevant transaction details. Provide a link to the order tracking page or the customer's order history in their account. Add your customer service contact information so customers know how to reach you if something is wrong.

Keep the design clean and mobile-friendly. More than half of all emails are read on mobile devices. Use a single-column layout, large readable text (minimum 14px for body text), and buttons with adequate touch targets (minimum 44px height). Your order confirmation email is a reflection of your store's professionalism. Invest the time to get it right.

For more details, read our guides: Email Configuration in PrestaShop: SMTP, Gmail and Transactional Email and Order Status Workflow in PrestaShop: Customization and Automation.

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

For more details, read our guides: Is Your Store Slow? How to Check and What to Do About It and Essential PrestaShop Modules: The Must-Have List for Every Store.