What we need to start your store audit — access, data safety & GDPR

What we need to start your store audit — and how we keep your data safe

Every Expert Service audit is run by a specialist on your real PrestaShop store, not on a generic demo or a checklist filled in from a distance. To do that well we need a little information up front — and because that sometimes means granting access, this page is just as much about how we protect your store and your customers' data. The short version: we work read-only by default, we ask for the least access possible, and we never touch or take your customer data.

1. Your store URL (required)

On every audit product page you will see a Store domain / URL field with a Check readiness button. Enter your shop's public address (for example https://your-store.com) and click it. We run an instant, read-only check that confirms the store is reachable over HTTPS, that the TLS certificate is valid, and that it looks like PrestaShop. Nothing is changed on your shop. Once the check passes, the audit is added to your cart and your store URL travels with the order, so we know exactly which shop to audit.

The readiness check is the same kind of request any visitor's browser makes — it loads your public pages and reads what they already expose. It does not log in, does not probe private areas, and does not write anything. Use the public address your customers actually visit, including the correct subdomain and language path if your shop runs on more than one. If your store sits behind a maintenance screen, a staging password, or an IP allow-list, just tell us during intake so the specialist can still reach it.

2. Search Console / analytics access (recommended, not required)

For an SEO Audit, delegated read access to Google Search Console sharpens the findings. It is optional, granted from your own account, and revocable in one click at any time — we never ask for your password.

Why it helps: Search Console shows how Google actually crawls and ranks your store — the queries you appear for, the pages that win or lose impressions, indexing problems, and manual actions. That real-world data lets the audit move from "this could matter" to "this is what is costing you traffic, and here is the page." You grant it through Google's own sharing, at Restricted (read-only) level, to the e-mail address we give you during intake; we never see your Google password, and you can remove our access the moment the audit is delivered. The same applies to read access to Google Analytics if you would like the SEO or performance findings backed by your own traffic figures. None of this is mandatory — an SEO audit still runs on your public URL alone — but it makes the report more specific to your shop.

3. Admin or hosting access (only when it adds value)

Most audits are performed from the outside, the way Google and your customers see the store. When read access genuinely helps — typically a Security Audit or Hosting Audit — the safest pattern is to create a temporary, read-only employee account for us and delete it when we are done. We ask for the least privilege a given audit needs, and we never need access to your customer or order database.

If admin access is useful for your audit, here is the pattern we recommend, because it keeps you in control the whole time:

• Make a dedicated account, not a shared one. Create a new employee or a limited admin profile for us rather than handing over an existing login. That way the access is clearly ours, clearly scoped, and clearly traceable in your shop's logs.
• Keep it read-only where PrestaShop allows. Grant view permissions on the areas the audit needs and leave create, edit and delete switched off. If a particular check requires a setting to be visible only, that is all we ask for.
• Time-box it. Enable the account for the audit window and disable or delete it as soon as we deliver — we will remind you to do exactly that.
• Send credentials separately and securely. Share the login over a channel you trust, ideally splitting the username and password, and avoid pasting passwords into plain e-mail. Reset or remove the account afterwards so the credentials no longer work.

For a hosting audit, the same principle applies to server or control-panel access: a scoped, temporary, read-only login is enough to inspect configuration, logs and resource usage. We do not need root, we do not need write access, and we never need to reach your customer or order tables.

Your data — and your customers' data — stays safe

These are not slogans; they are the rules the specialist follows on every job. If anything about a particular audit would need an exception, we raise it with you first and put it in writing.

• Read-only by default. An audit is a diagnosis. We look, measure and report — we never change anything on your store without a separate, written, agreed scope.
• Least access, time-boxed, revocable. We ask only for what a given audit needs, for as long as it needs it, and we will remind you to revoke it the moment we are finished.
• We don't copy, export or keep your customer data. Audits look at configuration, structure, code and public signals — not your customer or order records. If a specific check ever needs database access it is read-only, and we never extract personal data.
• Nothing is kept afterwards. When the audit is delivered we do not retain your data — unless you specifically ask us to hold a backup for you.
• We never put your store on display. We do not use your shop as a case study, portfolio piece or example — not even anonymized — without your written agreement. If you are happy to be featured, we will gladly thank you with a discount.
• Your report is yours. Findings are shared only with you, stored securely, and never reused or passed on to anyone else.

The thread running through all of these is the principle of least privilege: the smallest amount of access, for the shortest time, with the fewest people, and nothing kept that does not have to be. It is the same standard we would want any outside specialist to apply to our own shop.

What you can prepare before we start

None of this is required to place an order, but a few minutes of preparation makes the audit faster and leaves you with extra peace of mind:

• Take a fresh backup. Even though an audit is read-only, a current backup of your files and database is simply good practice before anyone looks at a live shop. Store it somewhere safe and confirm it actually restores.
• Consider a staging copy. If your audit involves admin or server access and you would rather we never touch the live environment, point us at a staging or clone instead. Many findings transfer directly back to production.
• Know your hosting setup. For performance and hosting audits, having your PHP version, PrestaShop version, hosting type and any caching or CDN details to hand lets us get straight to the analysis.
• Write down the symptoms. Whatever prompted the audit — a traffic drop, slow pages, a checkout issue, a suspicious login — note when it started and what you have already tried. Context turns a good report into a precise one.
• Decide your access comfort level in advance. If you would prefer URL-only, say so. If you are happy to grant scoped read access, prepare the temporary account so it is ready when the specialist begins.

GDPR & confidentiality

We are an EU-based company (Tychy, Poland), so GDPR is our baseline, not an afterthought. When an audit involves any access to personal data, we act strictly as a processor on your instructions, for that audit only and for no other purpose — we do not transfer your data, reuse it, train anything on it, or market to anyone. If your compliance team needs it, we are happy to sign an NDA or a data processing agreement before we begin; just ask during intake. For your own store's GDPR posture, see our PrestaShop GDPR guide.

In practice this means we treat your store's data the way the regulation expects a processor to: access is limited to the specialist doing the work, used only for the agreed audit, and not held a moment longer than that audit needs. Because we are based in the EU, your data does not leave the bloc for our purposes. If you would like the relationship documented before any access is granted, an NDA and a data processing agreement can both be in place before the work starts — bring them up during intake and we will sort the paperwork first. If you want to understand the wider picture of how we approach confidentiality and store hardening, our Security Audit page covers the same mindset applied to your shop itself.

If you would rather we never touch personal data at all, say so — most audits (SEO, performance, theme, hosting) are done entirely from the outside, with nothing more than your public store URL.

What to expect from the audit itself

Once the readiness check passes and the order is placed, a specialist examines your store against the scope you chose. We work through configuration, structure, code and public signals, cross-check anything that access lets us confirm, and write up what we find. You receive a clear report: what is working, what is holding you back, and what to do about it, prioritised so you can act on the things that matter most first.

The report is written to be useful whether or not you ever buy anything else from us. Where a finding points to a fix, we explain the fix in plain terms — sometimes that is a setting, sometimes content, sometimes hosting, and sometimes a module. We tell you which, and why.

What each audit needs

A quick reference for what to have ready before you run the readiness check on each service:

• SEO Audit — store URL; ideally Search Console read access.
• Security Audit — store URL; optionally temporary read access to confirm configuration.
• Performance Audit — store URL, hosting type, the symptoms you have noticed.
• Feed & Tracking, Module Fit, Theme Fit — store URL and your goal.

An honest word on modules

Many fixes can be implemented with our open-code tooling — SEO Revolution, Security Revolution, Performance Revolution. But an audit's job is to tell you whether a module is the right answer, not to push one. Sometimes the fix is configuration, content or hosting — and we will say so. Pick the audit that fits on the Expert Services page, run the readiness check, and we will take it from there.