Optimizare magazin online PrestaShop: studiu de caz Intimall

• Agenția WEB22 Timișoara
• 25.09.2026

Optimizare magazin online PrestaShop: studiu de caz Intimall

Un magazin construit de noi, readus la standardele din 2026

Intimall este un magazin online din Dumbrăvița, Timiș, care vinde lenjerie intimă, dresuri, șosete, lenjerie termică din lână merino, cosmetice și produse pentru casă. Magazinul l-am construit tot noi, pe PrestaShop, iar în câțiva ani de funcționare a acumulat ce acumulează orice magazin viu: produse adăugate în grabă, module instalate pe rând, scripturi de marketing puse direct în temă, texte fără diacritice și o hartă a site-ului care nu mai corespundea realității.

Am făcut un refresh complet, tehnic și vizual, direct pe magazinul live, fără să oprim vânzările și fără să pierdem nimic din indexarea existentă: SEO tehnic și date structurate pentru e-commerce, conținut rescris pentru toate produsele și categoriile, design nou pe identitatea existentă și performanță. Am adăugat și un obiectiv nou: magazinul să poată fi citit și folosit corect de asistenții AI și agenții de navigare, nu doar de Google.

Ce am găsit la audit

Am pornit, ca de obicei, de la sursa paginilor și de la ce răspunde serverul, nu de la scorul PageSpeed. Am verificat automat toate adresele din harta site-ului trimisă la Google și sursa fiecărui tip de pagină. Cele mai costisitoare probleme nu se vedeau deloc în magazin:

• Harta site-ului era aproape în întregime greșită. Din 247 de adrese, doar 9 răspundeau direct. 207 erau adrese vechi, cu ID în URL, care făceau redirect temporar (302), iar 31 duceau la pagina de eroare 404.
• 61 de produse retrase din ofertă aveau încă adrese indexate care duceau la 404.
• Datele structurate se contraziceau. Cineva adăugase manual un bloc Schema.org în header, peste cel generat de temă, iar șabloanele produselor aveau și microdata. Rezultatul: firma declarată de două ori, cu date diferite, și nicio politică de retur sau de livrare pentru Google Shopping.
• Prima pagină nu avea niciun H1.
• Adresa și telefonul diferă de la o pagină la alta. Termenii și condițiile și alte pagini legale păstrau o adresă veche.
• Numele produselor erau scrise cu majuscule, cu simbolul ® și fără diacritice, iar descrierile erau scurte sau copiate de la producător.
• Google Tag Manager, Facebook Pixel și Google Analytics se încărcau înaintea conținutului, iar widgetul Elfsight pentru recenziile Google adăuga o bibliotecă JavaScript întreagă pentru un rând de stele.
• Pe desktop, paginile de categorie și de produs „săreau” vizibil la încărcare: CLS 0,7, de șapte ori peste pragul acceptat de Google.

SEO tehnic pentru e-commerce: adrese curate, redirecturi permanente, un singur graf de date

Pentru un magazin, SEO tehnic înseamnă în primul rând că fiecare produs și fiecare categorie are o singură adresă, stabilă și clară, iar toate adresele vechi duc permanent la cea nouă.

• Adrese fără ID-uri pentru produse, categorii, branduri și pagini, cu redirect permanent 301 de pe toate adresele vechi. Cele 207 redirecturi temporare au devenit permanente, ca autoritatea paginilor vechi să treacă pe cele noi.
• Produsele retrase trimit acum permanent spre categoria lor, nu spre o pagină de eroare.
• Harta site-ului dinamică, împărțită pe produse, categorii, branduri, pagini și articole: 285 de adrese, toate valide. Categoriile fără produse active sunt excluse automat și revin singure când primesc produse. Sitemap-ul a fost retrimis în Google Search Console.
• Noindex pe căutările interne, pe sortări și pe variantele filtrate, ca Google să nu indexeze mii de combinații duplicate.
• Un singur graf JSON-LD, generat automat pe fiecare tip de pagină, în locul blocurilor manuale și al microdatelor care se contraziceau.

Conținut: fiecare produs, categorie și pagină rescrisă

Pentru un magazin, textul de pe pagina de produs contează la fel de mult pentru Google ca pentru client. L-am tratat ca pe o parte a proiectului, nu ca pe un detaliu:

• 154 de produse rescrise complet: nume curate cu diacritice, descriere scurtă, descriere lungă structurată (beneficii, detalii, îngrijire, întrebări frecvente), meta titlu și meta descriere. Am folosit doar informațiile reale ale produsului, fără certificări sau procente inventate.
• 43 de categorii cu nume corecte, descrieri și meta date noi, plus 47 de branduri care nu aveau deloc descriere pentru Google.
• 12 articole noi pe blog, de 1.000–1.400 de cuvinte fiecare, construite pe întrebări reale ale clientelor (cum alegeți mărimea sutienului, ce înseamnă DEN la dresuri, cum purtați lenjeria termică din lână merino), cu legături interne spre categorii.
• Paginile legale și de informare (livrare, retur, termeni, confidențialitate) au primit adresa și telefonul corecte, structură cu subtitluri și un ton unitar, cu „dumneavoastră”.
• 461 de texte ale interfeței (coș, checkout, cont, formulare, mesaje) corectate: diacritice, ton formal, formulări clare. „Autentifica-te in contul tau” a devenit „Autentificați-vă în contul dumneavoastră”.

Design: aceeași identitate, un magazin mult mai ușor de folosit

Culorile și logo-ul au rămas. Tot restul a fost refăcut după tiparele magazinelor mari de azi, cu atenție specială la telefon, de unde vin majoritatea comenzilor:

• Layout „boxed” de 1560 px, cu header, conținut și footer aliniate pe același container. Căutarea e mare și centrală, iar butoanele contului și coșului sunt rotunde, cu etichete.
• Prima pagină, construită în Elementor, are un hero neutru în format bento: lenjerie, dresuri, șosete, cosmetice și produse pentru casă. Magazinul nu mai pare doar un magazin de lenjerie.
• Filtre în coloana din stânga pe desktop, vizibile tot timpul la derulare. Pe telefon apar într-un panou care urcă de jos, se aplică imediat și se închid cu „Vezi produsele”.
• Paginare de 24 de produse în locul încărcării infinite, două produse pe rând pe telefon și titluri limitate la trei rânduri.
• Pagina de produs: galerie și informații aliniate cu restul site-ului, brandul discret deasupra titlului, tab-uri sub galerie și o listă scurtă de garanții (livrare, termen, retur, plată) lângă butonul de coș.
• Coș, checkout și cont refăcute: modal de confirmare cu totalul evidențiat, coș lateral aerisit, pași de comandă numerotați, opțiuni de livrare ca și carduri, formulare pe două coloane și, pe telefon, meniul contului ca acordeon.

Performanță: marketingul nu mai blochează magazinul

Un magazin trăiește din reclame, deci scripturile de marketing nu pot fi scoase. Le-am mutat însă acolo unde nu mai încurcă:

• Google Tag Manager, Facebook Pixel și Google Analytics pornesc la prima interacțiune a vizitatorului sau la 3,5 secunde după încărcare. Datele de trafic rămân complete, dar pagina se afișează fără ele.
• CSS critic inline: stilurile necesare primei ecranări sunt direct în pagină, iar foaia completă se încarcă asincron. Pe paginile de coș și checkout păstrăm încărcarea clasică, pentru siguranță.
• Fontul Jost e găzduit local, ca un singur fișier variabil. Google servea telefonului altă variantă decât preîncărcarea, deci pe mobil fontul se descărca de două ori.
• Widgetul Elfsight a dispărut. Ratingul Google (4,9 din 54 de recenzii) apare ca text simplu, fără nicio bibliotecă în plus.
• Proporții fixe pentru imaginile de produs: saltul vizual pe desktop a scăzut de la 0,7 la 0.

Accesibilitate și agenți AI: magazinul poate fi folosit și de un asistent

Browserele cu agenți AI, care compară prețuri sau finalizează comenzi în locul utilizatorului, citesc pagina prin arborele de accesibilitate, la fel ca un cititor de ecran. Un buton fără nume sau un câmp fără etichetă este invizibil pentru ei. Am corectat tot ce raportau testele:

• Butoane și iconițe cu nume accesibile (favorite, comparare, vizualizare rapidă, cantitate, căutare, rețele sociale, WhatsApp).
• Filtre, cursorul de preț și câmpurile formularelor cu etichete corecte, ordinea titlurilor reparată și contrast suficient pentru textele secundare.
• Un fișier llms.txt care descrie pe scurt magazinul, livrarea, returul și categoriile principale, pentru modelele de limbaj.

Problema pe care nu o arată niciun raport

La un moment dat, magazinul a răspuns foarte greu câteva minute, iar în cPanel memoria contului ajunsese la 2 GB din 2 GB și procesorul la 100%. Cauza era chiar o operație de rutină: golirea completă a cache-ului PrestaShop. Ea obligă magazinul să reconstruiască totul (containerul Symfony, șabloanele și fișierele CSS/JS combinate), iar dacă în același timp sosesc și vizitatori, fiecare cerere încearcă să reconstruiască același lucru.

Am schimbat procedura. Pentru o modificare de design regenerăm doar fișierul CSS combinat și îi schimbăm versiunea din adresă, ca browserele să îl descarce pe cel nou. Apoi golim doar cache-ul LiteSpeed. Serverul nu mai simte nimic.

Pe un hosting partajat, „golește cache-ul” nu e o operație gratuită. Pe un magazin cu trafic, contează când și cum o faci.

Unde am ajuns

Ce urmează

Pe mobil, scorul de performanță în testele de laborator este acum în jur de 75, cu accesibilitate și SEO la 100. Limita nu mai vine din scripturile de marketing, ci din JavaScript-ul temei (circa 380 KB), necesar pentru meniuri, galerii și coș. Următorii pași, pe care îi recomandăm oricărui magazin PrestaShop mai vechi:

• Imagini de produs în WebP, generate treptat, noaptea. Regenerarea tuturor miniaturilor dintr-o dată ar încărca serverul exact cum a făcut-o golirea cache-ului.
• Reducerea JavaScript-ului temei: scoaterea modulelor nefolosite și încărcarea pe pagină doar a scripturilor necesare.
• Google Merchant Center alimentat din aceleași date structurate (preț, stoc, livrare, retur), pentru listări gratuite în Google Shopping.
• Recenzii reale pe produse, care să alimenteze ratingul din rezultatele de căutare.
• Monitorizarea Core Web Vitals pe date reale de utilizare (CrUX), nu doar pe teste de laborator.

Întrebări frecvente despre optimizarea unui magazin PrestaShop

Ce puteți lua de aici, chiar dacă nu ne sunați

Verificați harta site-ului, nu doar magazinul. Deschideți sitemap.xml și testați câteva adrese. Dacă o parte fac redirect sau duc la 404, Google pierde timp pe ele în loc să indexeze produsele noi.

Căutați blocuri de date structurate adăugate manual. Un bloc Schema.org lipit „temporar” în header, peste cel generat de temă, poate contrazice datele reale ale magazinului.

Scrieți descrierile de produs pentru client. Beneficii clare, detalii reale, îngrijire și câteva întrebări frecvente valorează mai mult decât textul copiat de la producător, și pentru clientă, și pentru Google.

Încărcați marketingul după conținut. Pixelii și tag managerul pot aștepta o secundă. Clientul nu.

Dacă v-a fost util, citiți și studiul de caz despre SEO tehnic și indexarea AI pentru Prisma Glass și studiul de caz despre optimizarea on-site pentru Casa Preziosa.

Întrebări frecvente

Merită refăcut un magazin online sau doar optimizat?

Dacă platforma e actualizabilă și structura e sănătoasă, optimizarea e suficientă. Dacă tema e abandonată, modificată direct în cod sau blochează actualizările, un magazin nou costă mai puțin pe termen lung.

Ce se întâmplă cu pozițiile în Google după refacere?

Se păstrează, dacă adresele rămân aceleași sau sunt redirecționate corect. Planul de redirecturi se face înainte de lansare, nu după.

Cât durează un astfel de proiect?

Pentru un magazin cu câteva sute de produse, între 4 și 8 săptămâni, în funcție de integrări și de cât de repede se validează conținutul.