Jak szybko znaleźć zduplikowane opisy w sklepie internetowym? (Narzędzia i metody)

Najgorszy audyt duplikacji opisów zaczyna się od losowego klikania produktów. Po dwudziestu kartach wszystko wygląda podobnie, po pięćdziesięciu człowiek zaczyna widzieć duplikaty tam, gdzie ich nie ma, a po stu i tak nie wiadomo, czy problem dotyczy 3% asortymentu, czy połowy sklepu. Dlatego najpierw trzeba policzyć skalę, a dopiero potem planować poprawki.

W praktyce diagnostyka powinna dać trzy liczby: ile produktów ma identyczny opis, ile ma bardzo podobny opis, a ile stron może być problematycznych z punktu widzenia indeksacji, widoczności lub marnowania crawl budgetu. Nie chodzi jeszcze o przepisywanie treści. Nie chodzi też o ustalanie strategii technicznej. To etap rozpoznania: szybki, powtarzalny i możliwy do wykonania na eksporcie z narzędzi oraz bazy danych.

Dane o limitach i cenach narzędzi w tekście są aktualne na 11 czerwca 2026 r. Warto je sprawdzić przed zakupem, bo szczególnie ceny SaaS-ów i limity API potrafią zmienić się bez większego rozgłosu.

Google Search Console i crawl: szybki obraz skali problemu

Google Search Console nie powie wprost: „masz 1837 zduplikowanych opisów produktów”. To nie jest narzędzie do porównywania treści. Daje jednak coś ważniejszego na starcie: listę adresów, które realnie istnieją w ekosystemie Google — mają wyświetlenia, kliknięcia, problemy z indeksacją albo są widoczne w raportach. Od tego warto zacząć, bo w sklepie internetowym baza produktów często nie zgadza się z tym, co faktycznie widzi crawler.

Pierwszy krok: eksportuj z GSC strony produktowe z raportu Skuteczność → Wyniki wyszukiwania → Strony. Ustaw zakres 3–6 miesięcy, odfiltruj wzorzec URL typowy dla produktów, na przykład /produkt/, /p/, /product/, i pobierz dane do CSV, Excela albo Google Sheets. Trzeba pamiętać o ograniczeniu: eksport bezpośrednio z raportu GSC jest ucinany do 1000 wierszy reprezentatywnych danych, choć sumy w raportach nadal pokazują wartości całościowe. Google pozwala eksportować raporty między innymi do Google Sheets, Excela i CSV.

Przy małym sklepie to wystarczy do pierwszego sita. Przy sklepie z kilkoma tysiącami produktów już nie. Wtedy lepsza ścieżka to Search Console API albo eksport do BigQuery. API jest bezpłatne, ale ma limity użycia; dane raportu skuteczności są ograniczone do 50 tys. wierszy dziennie na typ wyszukiwania i usługę, a Google zaleca stronicowanie wyników przez startRow i pobieranie maksymalnie 25 tys. wierszy na zapytanie.

Dla dużego e-commerce najczystszy wariant to bulk data export do BigQuery, bo pozwala codziennie wysyłać dane Search Console do hurtowni i wykonywać zapytania SQL na większym zbiorze. Google zaznacza, że taki eksport obejmuje dostępne dane skuteczności dla usługi, z wyjątkiem zapytań anonimowych. Sam BigQuery ma darmowy próg: 10 GiB storage i do 1 TiB zapytań miesięcznie w on-demand compute; powyżej darmowego limitu Google podaje cenę startową 6,25 USD za TiB przeskanowanych danych.

Co konkretnie wyciągnąć z GSC?

• URL strony produktu
• kliknięcia
• wyświetlenia
• średnią pozycję
• CTR
• datę lub zakres dat
• opcjonalnie: urządzenie, kraj, typ wyszukiwania

Nie oceniaj duplikacji po samym spadku kliknięć. To częsty błąd. Strona produktu może mieć słaby ruch, bo produkt jest sezonowy, wyprzedany, nowy albo ma niszowy popyt. GSC ma tu inną rolę: pomaga ustalić, które duplikaty bolą najbardziej. Jeżeli grupa 200 produktów ma ten sam opis, ale 180 z nich nie ma żadnych wyświetleń, a 20 zbiera ruch, priorytetem diagnostycznym są te 20. One pokazują, gdzie problem może realnie dotykać widoczności.

Drugi krok: wykonaj crawl sklepu. Minimum to lista URL-i produktowych. Nie zaczynaj od całej domeny, jeżeli sklep ma filtry, parametry, sortowania, warianty i setki tysięcy adresów technicznych. Najpierw zbuduj czystą listę produktów z jednego z trzech źródeł:

• eksport z CMS lub PIM,
• sitemap produktowa,
• eksport URL-i z GSC.

W crawlerze interesują cię przede wszystkim: status HTTP, indexability, canonical, title, H1, liczba słów, hash treści, najbliższy podobny URL i liczba podobnych stron. Dopiero po połączeniu tych danych z GSC można rozsądnie powiedzieć: „problem dotyczy 900 aktywnych produktów, z czego 120 ma ruch organiczny, 300 jest indeksowalnych bez kliknięć, a 480 to martwy ogon”.

Granica decyzyjna jest prosta. Jeżeli masz do 500 adresów, możesz zrobić pierwszy przegląd nawet darmowym crawlerem. Jeżeli produktów jest więcej, darmowe limity zaczną fałszować obraz. Wtedy nie walcz z narzędziem, tylko użyj płatnego crawla albo pracuj na eksporcie z bazy.

Screaming Frog, Siteliner i Copyscape: kiedy użyć którego narzędzia

Najwięcej czasu traci się wtedy, gdy jedno narzędzie próbuje się zmusić do wszystkiego. Screaming Frog, Siteliner i Copyscape mają różne zastosowania. W audycie opisów produktów układam je tak: Screaming Frog do kontroli adresów i podobieństwa w obrębie crawla, Siteliner do szybkiego raportu wewnętrznego, Copyscape do sprawdzenia kopii poza sklepem albo dużych batchy tekstu.

Screaming Frog SEO Spider jest najlepszym narzędziem roboczym, gdy chcesz mieć kontrolę nad zakresem audytu. Wersja darmowa pozwala crawlowąć do 500 URL-i. Płatna licencja kosztuje obecnie 279 USD rocznie za użytkownika przy zakupie 1–4 licencji; przy większych pakietach cena spada do 265 USD, 249 USD albo 235 USD za licencję rocznie. Licencje są roczne i przypisane do użytkownika.

W Screaming Frogu są dwa różne światy duplikacji. Exact Duplicates wykrywa strony identyczne przez porównanie pełnego HTML-a z użyciem hashy MD5. To świetne do znalezienia adresów typu slash/non-slash, parametrów, kopii technicznych i stron wygenerowanych kilka razy. Near Duplicates działa na tekście strony, korzysta z algorytmu minhash i domyślnie oznacza podobieństwo od 90%; tę wartość można zmienić.

Praktyczna procedura w Screaming Frogu:

1. Wgraj listę URL-i produktowych w trybie List, jeżeli nie chcesz crawlowania całej domeny.
2. Przejdź do Config → Content → Duplicates.
3. Włącz Enable Near Duplicates.
4. Zostaw próg 90% na pierwszy przebieg.
5. Przejdź do Config → Content → Area i sprawdź, czy analiza obejmuje realny opis produktu, a nie menu, stopkę, rekomendacje i bloki promocyjne.
6. Uruchom crawl.
7. Po zakończeniu kliknij Crawl Analysis → Start, bo filtr Near Duplicates wymaga analizy po crawlu.
8. Wejdź w zakładkę Content i sprawdź filtry Exact Duplicates oraz Near Duplicates.
9. Wyeksportuj dane przez Bulk Export → Content → Exact Duplicates oraz Bulk Export → Content → Near Duplicates.

Najważniejszy niuans: Screaming Frog domyślnie sprawdza duplikaty dla stron indeksowalnych. To rozsądne przy diagnozie SEO, ale czasem ukrywa skalę bałaganu technicznego. Jeżeli szukasz marnowania crawla albo duplikatów w adresach nieindeksowalnych, trzeba wyłączyć opcję ograniczającą analizę tylko do indexable pages. Screaming Frog sam wskazuje, że near duplicates wymagają włączenia konfiguracji oraz wykonania Crawl Analysis, a wynik można eksportować masowo z raportu Near Duplicates.

Drugi niuans: nie analizuj całego layoutu, jeżeli sklep ma rozbudowane sekcje wspólne. Menu, stopka, boxy „ostatnio oglądane”, cross-sell i banery potrafią podnieść podobieństwo między stronami, które w opisie produktu wcale nie są duplikatami. Dlatego przy produktach najlepiej zawęzić analizę do kontenera opisu, na przykład .product-description, .description, #tab-description, zależnie od szablonu. Screaming Frog pozwala ustawić obszar treści przez klasy, ID i tagi HTML.

Siteliner jest szybszy i mniej techniczny. Wpisujesz domenę, narzędzie crawluje stronę i pokazuje raport o duplikatach, broken linkach oraz innych elementach jakościowych. Wersja darmowa jest ograniczona do miesięcznych analiz stron mających do 250 podstron. Siteliner Premium pozwala skanować do 30 tys. stron tak często, jak potrzeba, daje opcje kontroli zakresu skanu i pozwala zapisywać wcześniejsze wyniki.

Koszt Siteliner Premium jest prosty: 1 cent za zeskanowaną stronę, kredyty kupuje się z góry kartą lub PayPalem. API działa podobnie: skan kosztuje 1 cent za stronę, a pobranie wyników przez API również kosztuje 1 cent za request, który może zwrócić do 100 wierszy.

Kiedy użyć Sitelinera? Gdy chcesz szybko odpowiedzieć właścicielowi sklepu: „czy problem jest incydentalny, czy systemowy?”. Jest dobry jako pierwszy raport skali. Ma jednak ograniczenia. Jeżeli opis produktu ładuje się po stronie klienta, jest schowany za interakcją albo sklep blokuje boty, wynik może być niepełny. Siteliner deklaruje, że darmowy skan wybiera najważniejsze strony na podstawie struktury linkowania wewnętrznego, więc przy dużym sklepie może pominąć długi ogon produktów.

Copyscape ma inne zastosowanie. Nie zaczynam od niego audytu wewnętrznej duplikacji opisów, bo do tego wygodniejsze są Screaming Frog, Siteliner albo baza danych. Copyscape przydaje się, gdy podejrzewasz, że opisy są kopiowane z hurtowni, producenta, marketplace’u albo konkurencji. To ważne w branżach, gdzie sklepy masowo importują feed dostawcy i każdy ma ten sam blok tekstu.

Copyscape Premium kosztuje 3 centy za pierwsze 200 słów oraz 1 cent za każde kolejne rozpoczęte 100 słów. Premium pozwala między innymi wklejać tekst, uploadować dokumenty, używać API, budować Private Index i wykonywać Batch Search do 10 tys. stron w jednej operacji. API ma ten sam model cenowy co interfejs webowy i zwraca wyniki między innymi w JSON, XML albo HTML.

Decyzja narzędziowa bez lania wody:

• do 500 produktów: Screaming Frog Free + eksport z bazy do arkusza;
• do 5000 produktów: Screaming Frog płatny albo Siteliner Premium + filtrowanie bazy;
• powyżej 5000 produktów: baza danych jako główne źródło, Screaming Frog na próbce i walidacji, GSC do priorytetów;
• gdy problemem są opisy od producenta: Copyscape na próbkach kategorii, dostawców i bestsellerów;
• gdy trzeba monitorować cyklicznie: API, raport SQL i zapis historii wyników.

Nie kupowałbym narzędzia tylko po to, żeby raz potwierdzić coś, co widać w bazie. Jeżeli sklep ma opisy przechowywane w jednej tabeli, najtańszy i najdokładniejszy pierwszy audyt zaczyna się od SQL-a. Narzędzia crawlerowe są wtedy kontrolą rzeczywistości: pokazują, czy to, co jest w bazie, rzeczywiście trafia na stronę.

Filtrowanie bazy produktów: hash, normalizacja i priorytety audytu

Baza danych jest najszybszym miejscem do znalezienia identycznych opisów produktów. Nie renderuje JavaScriptu, nie czeka na crawl, nie płaci za każdy request. Ma jednak jeden problem: surowe dane są brudne. Dwa opisy mogą wyglądać identycznie dla użytkownika, ale różnić się spacjami, tagami HTML, encjami, znakami nowej linii albo kolejnością niewidocznych elementów.

Dlatego najpierw robimy normalizację opisu, a dopiero potem liczymy duplikaty. Minimalny zestaw pól w eksporcie:

• product_id
• sku
• url
• product_name
• category_id
• brand_id lub manufacturer_id
• supplier_id
• status
• stock_status
• description_html
• description_plain
• updated_at
• created_at

Pierwszy raport powinien rozdzielać produkty aktywne i nieaktywne. Inaczej audyt wygląda dramatycznie, bo wciąga archiwalne SKU, produkty wycofane, testowe importy i warianty, które nigdy nie miały być indeksowane. Moja granica: do raportu głównego biorę tylko produkty, które są aktywne, mają publiczny URL i nie są oznaczone jako technicznie ukryte. Produkty nieaktywne trafiają do osobnej zakładki.

Przykład dla PostgreSQL — wykrywanie identycznych opisów po normalizacji:

WITH normalized_products AS (
  SELECT
    product_id,
    sku,
    url,
    category_id,
    manufacturer_id,
    status,
    md5(
      regexp_replace(
        lower(
          regexp_replace(
            coalesce(description_html, ''),
            '<[^>]+>',
            ' ',
            'g'
          )
        ),
        '\s+',
        ' ',
        'g'
      )
    ) AS description_hash,
    length(
      regexp_replace(
        regexp_replace(coalesce(description_html, ''), '<[^>]+>', ' ', 'g'),
        '\s+',
        ' ',
        'g'
      )
    ) AS description_length
  FROM products
  WHERE status = 'active'
)
SELECT
  description_hash,
  count(*) AS product_count,
  count(DISTINCT category_id) AS categories_count,
  count(DISTINCT manufacturer_id) AS manufacturers_count,
  min(description_length) AS min_description_length,
  max(description_length) AS max_description_length,
  string_agg(product_id::text, ', ' ORDER BY product_id) AS product_examples
FROM normalized_products
WHERE description_length >= 80
GROUP BY description_hash
HAVING count(*) > 1
ORDER BY product_count DESC;

Dlaczego próg description_length >= 80? Bo krótkie opisy typu „Brak opisu”, „Opis w przygotowaniu”, „Produkt dostępny na zamówienie” albo puste szablony potrafią zawyżyć wynik. Nie usuwam ich z audytu, ale trzymam osobno jako placeholdery opisów, bo to inny problem niż zduplikowany opis produktowy.

Drugi raport: szablony i puste opisy. Tu nie potrzebujesz algorytmów podobieństwa, tylko prostych warunków:

SELECT
  CASE
    WHEN description_html IS NULL OR trim(description_html) = '' THEN 'pusty opis'
    WHEN lower(description_html) LIKE '%opis w przygotowaniu%' THEN 'opis w przygotowaniu'
    WHEN lower(description_html) LIKE '%brak opisu%' THEN 'brak opisu'
    WHEN length(regexp_replace(description_html, '<[^>]+>', ' ', 'g')) < 80 THEN 'bardzo krótki opis'
    ELSE 'inny'
  END AS issue_type,
  count(*) AS product_count
FROM products
WHERE status = 'active'
GROUP BY issue_type
ORDER BY product_count DESC;

Trzeci raport: podobne opisy, nie identyczne. Tu baza relacyjna nie zawsze jest idealnym narzędziem, bo porównywanie każdego produktu z każdym szybko robi się ciężkie. Dla 5000 produktów pełna macierz to prawie 12,5 mln par, a dla 50 tys. produktów — około 1,25 mld par. Da się to zrobić mądrzej: zawężaj porównania do kategorii, producenta, typu produktu albo długości opisu.

W PostgreSQL można użyć rozszerzenia pg_trgm i podobieństwa trigramowego:

CREATE EXTENSION IF NOT EXISTS pg_trgm;

WITH audit AS (
  SELECT
    product_id,
    category_id,
    manufacturer_id,
    regexp_replace(
      lower(
        regexp_replace(coalesce(description_html, ''), '<[^>]+>', ' ', 'g')
      ),
      '\s+',
      ' ',
      'g'
    ) AS norm_desc
  FROM products
  WHERE status = 'active'
)
SELECT
  a.product_id AS product_id_a,
  b.product_id AS product_id_b,
  a.category_id,
  similarity(a.norm_desc, b.norm_desc) AS similarity_score
FROM audit a
JOIN audit b
  ON a.category_id = b.category_id
 AND a.product_id < b.product_id
WHERE length(a.norm_desc) >= 300
  AND length(b.norm_desc) >= 300
  AND similarity(a.norm_desc, b.norm_desc) >= 0.85
ORDER BY similarity_score DESC;

Ten wynik nie jest wyrokiem. To lista par do kontroli. Przy opisach technicznych podobieństwo 85–90% może być uzasadnione, jeśli produkty różnią się jednym parametrem. Przy kategoriach modowych albo home decor taki wynik częściej oznacza automatycznie powielony opis z podmienioną nazwą koloru lub rozmiaru. Dlatego raport podobieństwa zawsze łącz z kategorią, producentem i typem wariantu.

Najlepszy raport dla biznesu nie powinien mieć 20 kolumn bez interpretacji. Uporządkuj go tak:

W arkuszu kalkulacyjnym dla mniejszego sklepu można zrobić prostszą wersję. Eksportujesz product_id, url, category, description, tworzysz kolumnę normalized_description, a potem liczysz powtórzenia.

Przykładowa formuła w Google Sheets:

=LOWER(REGEXREPLACE(REGEXREPLACE(TRIM(B2),"<[^>]+>"," "),"\s+"," "))

A obok:

=COUNTIF($C:$C,C2)

Jeżeli wynik jest większy niż 1, opis występuje więcej niż raz. Przy 5000 produktów to jeszcze działa. Przy większej bazie arkusz zacznie być powolny, a błędy filtrowania będą droższe niż szybkie zapytanie SQL.

Ostatni krok diagnostyczny to połączenie źródeł. Najlepiej przygotować jedną tabelę audytową:

product_id
sku
url
category
manufacturer
status
description_hash
duplicate_group_size
near_duplicate_count
gsc_clicks_3m
gsc_impressions_3m
indexable
canonical_url
http_status
source_tool
priority

Dopiero taka tabela daje odpowiedź, której potrzebuje sklep: „mamy 12 400 aktywnych produktów, 3180 ma opis powtórzony co najmniej raz, 740 należy do grup większych niż 10 produktów, a 126 z tych URL-i miało wyświetlenia z Google w ostatnich 3 miesiącach”. To jest diagnoza skali. Bez paniki, bez zgadywania, bez przeklikiwania 5000 kart.

💡Praktyczna wskazówka: Jak usunąć duplikację opisów produktów w e-commerce? (Strategie i rozwiązania techniczne).

FAQ: najczęstsze pytania o szybkie wykrywanie duplikatów opisów

Czy Google Search Console wystarczy do znalezienia zduplikowanych opisów?
Nie. GSC nie porównuje opisów produktów. Przydaje się do ustalenia, które URL-e mają widoczność, kliknięcia, wyświetlenia albo problemy indeksacyjne. Samą duplikację trzeba policzyć crawlerem, narzędziem typu Siteliner/Copyscape albo bezpośrednio w bazie.

Czy Screaming Frog wykrywa duplikaty opisów produktów, czy całych stron?
Wykrywa jedno i drugie, zależnie od ustawień. Exact Duplicates porównuje pełny HTML, a Near Duplicates analizuje tekst strony. Dlatego przy produktach trzeba dobrze ustawić obszar treści, żeby narzędzie nie porównywało menu, stopki i bloków rekomendacji.

Jaki próg podobieństwa ustawić w Screaming Frogu?
Na pierwszy przebieg zostaw 90%, bo to domyślna wartość dla Near Duplicates. Potem rozdziel kategorie. W produktach technicznych próg 90% może łapać uzasadnione warianty, a w kategoriach lifestyle’owych już 80–85% bywa sygnałem szablonowego opisu.

Czy Siteliner nadaje się do dużego sklepu?
Tak, ale jako szybki raport, nie jedyne źródło prawdy. Darmowy limit 250 stron jest za mały dla większości sklepów. Premium skanuje do 30 tys. stron, ale nadal trzeba sprawdzić, czy bot widzi pełne opisy i czy nie pomija części asortymentu przez strukturę linkowania, blokady albo JavaScript.

Kiedy użyć Copyscape?
Gdy chcesz sprawdzić, czy opisy są skopiowane z zewnętrznych źródeł: producenta, hurtowni, konkurencji, marketplace’u lub innych domen. Do czystej duplikacji wewnętrznej szybciej dojdziesz przez bazę, Screaming Frog albo Siteliner.

Czy identyczny hash opisu zawsze oznacza problem SEO?
Nie zawsze. Może dotyczyć produktów nieaktywnych, wariantów technicznych albo stron wyłączonych z indeksacji. Dlatego hash trzeba połączyć z danymi o statusie produktu, canonicalu, indexability i widoczności w GSC.

Czy warto ręcznie sprawdzać próbkę duplikatów?
Tak. Po raporcie automatycznym sprawdź 20–50 przykładów z największych grup. To szybciej ujawnia fałszywe alarmy: wspólne bloki, tabele parametrów, sekcje dostawy, źle wycięte HTML-e albo opisy wariantów, które faktycznie powinny być podobne.

Od czego zacząć, gdy sklep ma 5000 produktów?
Najpierw eksport z bazy i raport identycznych hashy. Potem crawl Screaming Frogiem lub Sitelinerem dla potwierdzenia tego, co jest na stronie. Na końcu połączenie z GSC, żeby ustalić, które grupy duplikatów mają największy priorytet.

Znalazłeś tysiące duplikatów? Nie panikuj. Przeczytaj, jak krok po kroku naprawić błędy i wdrożyć automatyzację – Jak usunąć duplikację opisów produktów w e-commerce? (Strategie i rozwiązania techniczne).