1. Prepare and plan a rollback
Check compatibility with your PrestaShop and PHP versions on the current product page. Download the package from your WO Software account. Back up files and the database, and record your existing protection settings. Start on a test environment if you have one.
Establish how to restore the previous configuration before making changes. Keep access to the administration panel and hosting. Early request protection may need a layer-specific rollback procedure; follow the instructions for your installed version.
2. Observe normal traffic
Check the active mode after installation. Set the layer you are evaluating to SHADOW and review whether other rules are already blocking. Do not enable every mechanism with restrictive limits at once. No single threshold is appropriate for every store.
Observe ordinary working hours, busier periods and background tasks. If imports run every few hours, include an import in the observation window. The aim is to understand normal behaviour.
3. Walk through the customer journey
Use both a computer and a phone, a new session and a test account. Check whether normal actions are marked as suspicious. A large number of detections is not helpful if it includes genuine purchases.
- Browse a category, filters and search.
- Choose a product combination and quantity.
- Add an item to the cart and continue browsing.
- Test login, registration, delivery and the payment transition in a test environment.
- Check required integrations and scheduled jobs.
4. Review the context of detections
Look for repeated expensive routes, unusual request frequency and repeated creation of new sessions or journeys. Compare the timestamp, route and rule with actual customer or integration activity. One IP address may represent multiple people.
Do not create broad exceptions just because a User-Agent mentions a familiar bot. Verify the source and purpose. Keep exceptions narrow and record why they were added.
5. Introduce protection gradually
Once you understand the results, change one protection layer or rule group. Repeat customer tests and watch errors and support reports. If something breaks, restore the previous configuration and isolate the triggering rule before trying again.
Measure more than blocked requests. Compare response times, server load and successful customer journeys over comparable periods. Keep a dated record of configuration changes.
6. Send an actionable support report
Include PrestaShop, PHP and module versions, active mode, approximate time and reproduction steps. Attach a sanitised diagnostic example. Do not include passwords, API keys or customer data in the problem description.
Option names may change between versions. The Traffic Guard Pro page below contains current features, requirements and supporting materials.