El Patron

Quick note — a common mistake many businesses make: .com is a U.S.-targeted gTLD, not international. I strongly recommend securing a .eu domain and eventually decommissioning the .com to avoid duplicate-content problems. Right now you have an even bigger issue: EU visitors landing on the .com experience missing carriers and a generally poor checkout flow because the shop isn’t aligned with their region. Moving to a .eu domain puts your entire product catalog in the correct regional context — something the current setup fails to do.

Hi, I don’t really have time to go through all the screenshots in detail, so please go ahead and fix any issues you’re seeing. You can also use SEMrush or similar tools to see who’s advertising and get ideas on how to improve and enhance the visitor experience. In short, either level up on how to make things better, follow experienced advice, and start closing the gap — you’ve got a hole to dig out of, so it’s time to start digging.

changing the front office especially if you bought directly from Leo, is the right thing to do and you know it in your gut. Also 1.7 has been riddled with hacks...me? create a staging copy of your production shop or if you have the budget use migration pro and migrate to fresh install of ps8.2.3 or wait for ps9.1 why migration to fresh installation is best, it leaves behind 'old' datas, modules etc that could/probably have vulnerabilities. only buy theme on addon's where it has to pass very vigorous validation process. using migration pro, you can build the entire shop, install awesome new theme...make sure everything works...then use migration pro to sync new customers/orders/products(for stock). put old shop in maintenance, move it to subdomain, clean domain and move new shop. done!

also consider 'high quality' 3rd party theme from addon's, unless you hire a design company to update your base ps theme, this is going to hurt your rankings. the base theme allows one to configure their shop get it all working but the expectation is to then upgrade to well designed theme, I see this so often, people using base ps theme which lacks advanced features like cool menu, avoid using tree category remove it once you have better filtering.

Hi, from experience I can share a few practical pointers that may help. You’re competing in a very tough niche for these industrial part numbers, and many of the other sites ranking for these models offer extremely polished catalogs. It’s worth reviewing some of your direct competitors and comparing what features, structure, or content they provide that your shop might be missing. For example, on this category page: https://aqdrive.com/12-drives the filter system appears misconfigured. The page shows 63 products, but the filters only show 1 item available. That creates a lot of friction for visitors who are trying to narrow down or locate the exact part they need. Even small UX or catalog-navigation issues like this can affect engagement metrics, and when combined with a very competitive industry, they can indirectly contribute to lower visibility in Google. Most often traffic drop occurs, based on poor visitors experience, google measure everything especially visits and fast bounce...here is one of my blog posts to help ps users know important things they can do to improve relevance. 1. Maybe Google Has Reclassified the Page as “Duplicate Content” Industrial part numbers (E82CV3712C, etc.) appear on hundreds of reseller sites with identical manufacturer descriptions. If Google detects: minimal original content mostly manufacturer text repeated patterns multiple URLs on your website with nearly identical product content …it may index the page but suppress it from search results. Check GSC → Coverage → Excluded: “Duplicate without user-selected canonical” “Duplicate, Google chose different canonical than user” “Alternate page with proper canonical” These reports confirm a duplicate-content canonicalization problem. 2. Sudden Drop in “Crawled – Currently Not Indexed” Check GSC → Coverage → Excluded. If you see a spike in: “Crawled – currently not indexed” starting around July 2025, Google is: crawling your pages deciding not to index the updated version relying on outdated cached versions therefore not ranking your product pages for model queries This often happens because: slow hosting thin content canonical tag mismatch conflicting SEO module duplicate URLs (with/without ID, parameter, category path) 3. Missing or Broken Product Schema Check the structured data using Google’s Rich Results Test: https://search.google.com/test/rich-results If product schema is missing or invalid, industrial part numbers often lose visibility.

I forgot, the best fishng lure? apple/amazon/little bit google....paypal instant pay. what is the best checkout? no checkout....when you pay with with instant payments, the automatically create account if none exists and updates orders after they pay via one of these 3 parties. it's not always easy in ps because you have to buy 3 modules (I don't use prestashop checkout as it can be limiting)...then on product/view cart/checkout(top) you offer instantpayments. then..we will wait to see if ps will update to offer agenic payments, i.e. via AI...however this is initially (last I heard) in US only.

Stripe paypal then it depends on what country you sell in and providing payment options they are comfortable with, klarna etc.

Composer is trying to load markbaker/matrix file adjoint.php, but that file is not on the server.” So after the migration, your /vendor directory is incomplete or mismatched with the rest of the shop. Re-upload from your backup (most common) On your old server backup (or local copy), locate the shop root and the vendor folder. On your computer, ZIP or tar only the vendor directory so you don’t miss anything. Upload that ZIP to the new server (SFTP/FTP, or via your hosting file manager). Unzip it into the shop root, so you end up with: /vendor/composer/... /vendor/markbaker/matrix/classes/src/Functions/adjoint.php After that, clear cache manually on the new server: Delete everything inside /var/cache/ (keep the cache folder itself). Then reload the back office/front office and see if the error disappears.

tell them to go with 8.2.3, wait for 9.1.0 or later version and then only upgrade if there is new must have feature. that's my best advice... https://prestaheroes.com/blogs/prestashop-alerts/prestashop-9-what-s-new-why-to-wait-and-how-to-prepare-for-the-upgrade

I have started using migration pro from addons. 1) using module upgrade process is tricky, it may be working for 9.0.1 but 9.0.0/1 are beta, .02 will have a of important fxes...9.1 will be the stable version and honestly I feel ps should have waited for 9.1 before releasing to general public, welcome to community tested loool. 2) using migration pro, you create fresh install and it imports known ps data's...not 3rd party you have to do that manually...the end result though is you will have clean domain files, no old module sources for example that may have vulnerabilities...etc that being said...if you did your upgrade from ps8 onto staging and your ps8 is in production wait for 9.1 or at least for 9.0.2 in summary and it's not clear to me exactly, but yes it could be something as simple as 8.4. go to 8.3 and see if that clears it up.

8.4 os9 is experimental highest recommended is 8.3 learn more here see of this solves if not post back here

Bonjour et bon après-midi, Voici quelques informations qui devraient vous aider : Le problème provient de l’hébergement OVH Perso : PrestaShop ne peut pas exécuter la commande php lorsqu’il tente de vider le cache. PrestaShop ne permet pas de configurer le chemin du PHP CLI. Votre serveur utilise PHP 8.4 pour la CLI, une version expérimentale qui n’est pas prise en charge par PrestaShop 9.0.1. La version la plus haute recommandée pour PS 9 est PHP 8.3. Le vidage de cache échoue en cours de route, ce qui laisse des fichiers manquants dans var/cache → d’où les erreurs 500 aléatoires dans le back-office. PrestaShop Checkout est connu pour être instable, surtout sur les hébergements mutualisés, et il déclenche souvent ce type d’erreur. Solutions recommandées : Désinstaller ou désactiver PrestaShop Checkout. Utiliser à la place le checkout natif de PrestaShop + les modules de paiement individuels (Stripe, PayPal, Amazon Pay, etc.), généralement beaucoup plus stables.Contacter OVH pour demander : le chemin exact du PHP CLI correspondant à votre version PHP (8.1 / 8.2 / 8.3), et si possible, rendre cette commande accessible via php. Vérifier votre version PHP web, et la ramener à 8.1–8.3 si nécessaire. Si vous suivez ces étapes, votre back-office devrait redevenir stable et éviter les erreurs 500 intempestives.

did not hear from you so I assume you got it working

if you are upgrading to ps9 here is something you will need to know. https://prestaheroes.com/blogs/prestashop-alerts/prestashop-9-urls-category-product-links-now-404-what-to-do

SEO can feel vague at times — what matters isn’t always clear, and figuring out where to start can be confusing, especially with older PrestaShop shops or newly upgraded 8.x/9.x installs. I created a free on-page SEO checklist based on real-world work I’ve done on customer shops over the years. This isn’t an attempt to solicit work — just sharing experience that might help merchants and developers get a cleaner starting point. The checklist covers: What matters most on product & category pages Practical meta title/description guidance Rich snippets & structured data basics Improving UX to reduce friction (terms popup, unnecessary modals, newsletter walls, etc.) Using FAQs, Q&A sections, and better attribute selection to boost engagement Simple steps that make long-term SEO easier to build on If you’re starting SEO cleanup, planning a redesign, or upgrading to PrestaShop 9, you may find it useful. Link to the checklist: https://prestaheroes.com/blogs/prestashop-alerts/the-on-page-seo-checklist-for-modern-prestashop-stores