WordPress automatycznie dodaje końcówki -2, -3, -4 i kolejne numery do bezpośrednich odnośników zdjęć. Najczęściej tłumaczy się to bardzo prosto: w bibliotece mediów znajduje się już plik o identycznej nazwie, dlatego system musi odróżnić jeden załącznik od drugiego. Jest to logiczne i powszechnie znane zachowanie WordPressa.
Ale co w sytuacji, kiedy w bibliotece mediów istnieje tylko jedno zdjęcie o danej nazwie, a WordPress mimo to dodaje do jego odnośnika końcówkę -4? Co więcej, nie pozwala jej usunąć, nawet gdy ręcznie zmieniamy uproszczoną nazwę załącznika?
Właśnie z takim przypadkiem zetknęliśmy się podczas administrowania stroną internetową opartą na WordPressie i WooCommerce. Nie chodziło o przypadkowe przesłanie dwóch zdjęć o identycznej nazwie. Problem był znacznie ciekawszy, ponieważ pozornie nie istniał żaden powód, dla którego WordPress miałby numerować odnośniki.
Początkowo podejrzewaliśmy błąd biblioteki mediów, pozostałości po usuniętych plikach, konflikt wtyczek, a nawet nieprawidłowe działanie bazy danych. Próbowaliśmy ręcznie zmieniać nazwy, ponownie przesyłać zdjęcia i korzystać z dodatkowych narzędzi.
Ostatecznie rozwiązanie znaleźliśmy w tabeli wp_posts. Okazało się, że WordPress działał prawidłowo, a przyczyną był mało oczywisty mechanizm nadawania unikalnych slugów załącznikom.
Jedno zdjęcie w bibliotece mediów, ale odnośnik z końcówką -4
Wszystko zaczęło się od aktualizacji grafiki o przykładowej nazwie kalendarz-wydarzen.jpg. Był to zwykły plik JPG wykorzystywany na stronie internetowej. W bibliotece mediów znajdował się tylko jeden obraz o tej nazwie.
Po otwarciu szczegółów załącznika WordPress wyświetlał jednak następujący bezpośredni odnośnik:
https://example.com/strona-glowna/kalendarz-wydarzen-4/
Dlaczego -4? Skoro nie było trzech innych zdjęć o nazwie kalendarz-wydarzen, trudno było znaleźć logiczne wyjaśnienie.
Co więcej, wcześniej podobny załącznik miał odnośnik zakończony na -2. Pojawiło się więc podejrzenie, że każde usunięcie zdjęcia i ponowne przesłanie nowej wersji powoduje zwiększanie numeracji.
Stosowana procedura aktualizacji grafik była prosta: usuwaliśmy poprzedni obraz z biblioteki mediów, przygotowywaliśmy nowy plik o tej samej nazwie i przesyłaliśmy go ponownie do WordPressa.
Czy system pozostawiał po usuniętych zdjęciach jakieś niewidoczne rekordy? Czy biblioteka mediów nie usuwała wszystkich informacji o załącznikach? A może WordPress posiada mechanizm zapamiętujący wcześniej wykorzystane nazwy?
Na tym etapie każda z tych możliwości wydawała się prawdopodobna.
Pierwsze podejrzenie: pozostałości po usuniętych zdjęciach
WordPress przechowuje informacje o załącznikach w bazie danych. Każde przesłane zdjęcie otrzymuje własny rekord, identyfikator oraz zestaw metadanych.
Naturalnym podejrzeniem było więc to, że wcześniejsze wersje zdjęcia nie zostały całkowicie usunięte i nadal zajmują kolejne nazwy.
W takim przypadku mogłoby dojść do sytuacji, w której fizyczny plik nie istnieje już na serwerze, ale powiązany z nim rekord nadal znajduje się w bazie danych.
Warto jednak pamiętać, że WordPress rozróżnia trzy elementy:
- Nazwę fizycznego pliku, np.
kalendarz-wydarzen.jpg. - Slug załącznika, np.
kalendarz-wydarzen-4. - Bezpośredni odnośnik załącznika, np.
/strona-glowna/kalendarz-wydarzen-4/.
To nie są trzy nazwy tego samego elementu. Są to odrębne wartości, które WordPress wykorzystuje do różnych celów.
Fizyczny plik może nadal nazywać się kalendarz-wydarzen.jpg, mimo że strona załącznika posiada adres zakończony na -4.
Ręczna zmiana uproszczonej nazwy niczego nie rozwiązała
Pierwszym krokiem była próba zmiany slugu bezpośrednio w panelu administracyjnym WordPressa.
Zamiast kalendarz-wydarzen-4 wpisaliśmy:
kalendarz-wydarzen
Po zapisaniu zmian WordPress ponownie przywracał końcówkę -4.
Wyglądało to tak, jakby system ignorował wprowadzone zmiany albo nieprawidłowo zapisywał dane.
W rzeczywistości zachowanie to wskazywało, że podstawowa nazwa nie była dostępna. WordPress automatycznie przywracał unikalny wariant.
Na tym etapie nie wiedzieliśmy jednak, co dokładnie blokuje wybraną nazwę.
Próba rozwiązania problemu za pomocą Phoenix Media Rename
Kolejnym krokiem było wykorzystanie wtyczki Phoenix Media Rename, umożliwiającej zmianę nazw plików znajdujących się w bibliotece mediów.
Wtyczka jest przydatna, gdy chcemy zmienić fizyczną nazwę przesłanego zdjęcia, na przykład z IMG_1234.jpg na bardziej opisową.
W naszym przypadku nie rozwiązała jednak problemu. Bezpośredni odnośnik załącznika nadal zawierał niechcianą końcówkę.
Nie oznaczało to błędu wtyczki. Problem nie dotyczył samej nazwy pliku JPG, ale wartości post_name przechowywanej w bazie danych WordPressa.
Był to pierwszy ważny wniosek: zmiana nazwy fizycznego zdjęcia nie musi zmieniać jego slugu ani usuwać konfliktu z innymi elementami strony.
Eksperyment: usuwamy zdjęcie i przesyłamy je ponownie
Postanowiliśmy sprawdzić, czy numeracja rzeczywiście zwiększa się przy każdym ponownym przesłaniu zdjęcia.
Usunęliśmy załącznik z biblioteki mediów, a następnie przesłaliśmy ponownie plik o tej samej nazwie.
Jeżeli WordPress automatycznie zapamiętywał każde wcześniejsze przesłanie, nowy odnośnik powinien otrzymać końcówkę -5.
Tak się jednak nie stało.
Nowy załącznik ponownie otrzymał slug:
kalendarz-wydarzen-4
To był przełomowy moment. Eksperyment pokazał, że WordPress nie zwiększa numeru przy każdym kolejnym przesłaniu pliku.
System wybierał -4, ponieważ właśnie ten wariant był dostępny. Wcześniejsze nazwy musiały być zajęte przez inne rekordy.
Pozostało ustalić, jakie.
Analiza bazy danych w phpMyAdmin ujawniła przyczynę
Zdecydowaliśmy się sprawdzić bezpośrednio bazę danych WordPressa.
W phpMyAdmin wykonaliśmy zapytanie:
SELECT ID, post_title, post_name, post_type, post_statusFROM wp_postsWHERE post_name LIKE 'kalendarz-wydarzen%';
Prefiks wp_ jest przykładowy. W konkretnej instalacji może być inny.
Wynik okazał się zaskakujący. Baza danych zawierała cztery rekordy o podobnych slugach, ale tylko jeden był załącznikiem graficznym.
| Slug | Typ rekordu |
|---|---|
| kalendarz-wydarzen | nav_menu_item |
| kalendarz-wydarzen-2 | nav_menu_item |
| kalendarz-wydarzen-3 | nav_menu_item |
| kalendarz-wydarzen-4 | attachment |
Trzy pierwsze rekordy były elementami menu nawigacyjnego WordPressa.
Nie były to stare zdjęcia, pozostałości po usuniętych plikach ani duplikaty załączników.
Po sprawdzeniu konfiguracji menu potwierdziliśmy, że rzeczywiście znajdowały się w nim trzy pozycje związane z kalendarzem wydarzeń.
Wszystko zaczęło układać się w logiczną całość.
WordPress nadawał zdjęciu końcówkę -4, ponieważ trzy wcześniejsze warianty slugu były już wykorzystywane przez elementy menu.
Nie miało znaczenia, że w bibliotece mediów znajdowało się tylko jedno zdjęcie o tej nazwie.
Dlaczego elementy menu mogą blokować nazwy zdjęć?
Odpowiedź znajduje się w architekturze WordPressa.
Tabela wp_posts, wbrew swojej nazwie, nie przechowuje wyłącznie artykułów blogowych. Znajdują się w niej również strony, załączniki, elementy klasycznych menu nawigacyjnych, rewizje i inne rodzaje treści.
Poszczególne rekordy rozróżniane są za pomocą kolumny post_type.
| Typ rekordu | Znaczenie |
|---|---|
| post | Artykuł blogowy |
| page | Strona |
| attachment | Załącznik multimedialny |
| nav_menu_item | Element klasycznego menu |
| revision | Rewizja wpisu |
Każdy rekord może posiadać własny slug zapisany w kolumnie post_name.
Co istotne, WordPress stosuje dla załączników szczególne zasady unikalności nazw. Podczas generowania slugu załącznika sprawdza, czy wybrana nazwa nie jest już wykorzystywana przez inny rekord.
W rezultacie nazwa zajęta przez element menu może uniemożliwić nadanie identycznego slugu zdjęciu.
W naszym przypadku trzy elementy menu zajmowały kolejno nazwy podstawową, -2 oraz -3. Nowy załącznik otrzymywał więc -4.
To właśnie ten mechanizm początkowo wyglądał na błąd.
Kolejna obserwacja: zdjęcie z końcówką -2, mimo że występuje tylko w jednym artykule
Po rozwiązaniu pierwszej zagadki zaczęliśmy analizować inne zdjęcia w bibliotece mediów.
Zauważyliśmy, że część grafik przypisanych do artykułów blogowych również posiada końcówkę -2, mimo że nie istnieją ich duplikaty.
Przykładem może być fikcyjny artykuł zatytułowany „Jesienny spacer po górach – najpiękniejsze szlaki”.
Jego slug wygląda następująco:
jesienny-spacer-po-gorach-najpiekniejsze-szlaki
Jeżeli zdjęcie wykorzystane w artykule otrzyma identyczny slug, WordPress może nadać mu:
jesienny-spacer-po-gorach-najpiekniejsze-szlaki-2
Dlaczego?
Ponieważ podstawowa nazwa jest już zajęta przez artykuł.
Nie ma znaczenia, że zdjęcie występuje tylko w jednym wpisie i że w bibliotece mediów nie ma drugiego pliku o identycznej nazwie.
Wystarczy konflikt z istniejącym rekordem post.
Ta obserwacja wyjaśniła, dlaczego końcówki -2 często pojawiają się przy zdjęciach, których nazwy są identyczne ze slugami artykułów.
Co ciekawe, taka sytuacja może być szczególnie częsta na stronach optymalizowanych pod SEO, gdzie nazwy plików graficznych są celowo dopasowywane do tematyki i tytułów publikacji.
Dwa pliki z różnymi rozszerzeniami również mogą powodować konflikt
Trzecim przypadkiem były dwa pliki wykorzystywane jako logotyp strony.
Załóżmy, że w bibliotece mediów znajdują się:
logo-firmy.jpg
logo-firmy.gif
Są to dwa różne pliki. Mają inne rozszerzenia, mogą mieć inną zawartość i bez problemu współistnieją w tym samym katalogu na serwerze.
Jednak podczas generowania slugów WordPress nie wykorzystuje rozszerzenia pliku jako części nazwy odróżniającej załączniki.
Dlatego pierwszy plik może otrzymać slug:
logo-firmy
A drugi:
logo-firmy-2
Warto podkreślić, że nie oznacza to automatycznej zmiany fizycznej nazwy pliku na logo-firmy-2.gif.
WordPress może przechowywać oba pliki pod ich oryginalnymi nazwami, a numerację zastosować wyłącznie w slugach załączników.
To kolejny przykład pokazujący, że mechanizm unikalności dotyczy rekordów w bazie danych, a nie wyłącznie plików na serwerze.
Jak działa mechanizm unikalnych slugów w WordPressie?
Za ustalanie unikalnych nazw odpowiada między innymi funkcja wp_unique_post_slug() znajdująca się w rdzeniu WordPressa.
Jej działanie zależy od rodzaju treści. Inne reguły mogą obowiązywać dla zwykłych artykułów, inne dla stron hierarchicznych, a jeszcze inne dla załączników.
W przypadku załączników WordPress stosuje szeroką kontrolę unikalności slugów.
Jeżeli nazwa jest już zajęta, system sprawdza kolejny wariant z liczbową końcówką.
Dla przykładu:
kalendarz-wydarzen– nazwa zajęta.kalendarz-wydarzen-2– nazwa zajęta.kalendarz-wydarzen-3– nazwa zajęta.kalendarz-wydarzen-4– nazwa dostępna.
WordPress wykorzystuje pierwszy odpowiedni wariant, który spełnia zasady unikalności.
Warto również zaznaczyć, że mechanizm nie działa identycznie dla wszystkich rodzajów wpisów. Zwykłe artykuły mogą mieć inne zasady unikalności niż załączniki, dlatego nie należy zakładać, że każdy slug w całej bazie musi być bezwzględnie unikalny.
Jak sprawdzić, co blokuje nazwę zdjęcia?
Jeżeli WordPress automatycznie dodaje końcówkę -2, -3 lub -4, a w bibliotece mediów nie ma duplikatów, warto sprawdzić tabelę wp_posts.
Dla przykładowego pliku kalendarz-wydarzen.jpg można wykorzystać:
SELECT ID, post_title, post_name, post_type, post_statusFROM wp_postsWHERE post_name LIKE 'kalendarz-wydarzen%';
Zapytanie pokaże wszystkie rekordy, których slug zaczyna się od wskazanej nazwy.
Jeżeli chcemy sprawdzić daty ich utworzenia i modyfikacji, możemy wykonać:
SELECT ID, post_name, post_type,post_date, post_modifiedFROM wp_postsWHERE post_name LIKE 'kalendarz-wydarzen%'ORDER BY ID;
Dzięki temu można ustalić, czy nazwy zajmują załączniki, artykuły, strony czy elementy menu.
Zapytania mają charakter diagnostyczny i nie zmieniają danych.
Należy jednak pamiętać, że nie każdy konflikt musi być widoczny wyłącznie na podstawie takiego wyszukiwania. Na nadawanie slugów mogą wpływać również zarezerwowane nazwy, struktura adresów oraz dodatkowe mechanizmy wtyczek.
Czy warto ręcznie usuwać końcówki -2 i -4?
W większości przypadków nie ma takiej potrzeby.
Jeżeli zdjęcie działa prawidłowo, a jego fizyczna nazwa jest poprawna, końcówka w slugu załącznika zazwyczaj nie stanowi problemu.
Technicznie można zmienić slugi rekordów powodujących konflikt, ale wymaga to ostrożności.
W przypadku elementów menu zmiana wewnętrznego slugu zwykle nie wpływa na widoczną etykietę ani adres docelowy pozycji menu. Nie należy jednak bez potrzeby modyfikować rekordów w bazie danych.
Jeszcze większą ostrożność należy zachować, jeżeli nazwa zdjęcia koliduje ze slugiem opublikowanego artykułu.
Zmiana adresu artykułu wyłącznie po to, aby zdjęcie mogło otrzymać nazwę bez końcówki, byłaby zazwyczaj nieuzasadniona.
Przed jakąkolwiek ręczną modyfikacją bazy należy wykonać kopię zapasową i sprawdzić powiązania danego rekordu.
Czy końcówki liczbowe w adresach zdjęć mają wpływ na SEO?
Sama końcówka -2 lub -4 w slugu załącznika nie oznacza pogorszenia pozycjonowania strony.
Warto rozróżnić dwa rodzaje adresów.
Adres strony załącznika:
https://example.com/artykul/jesienny-spacer-po-gorach-2/
Adres fizycznego pliku:
https://example.com/wp-content/uploads/2026/10/jesienny-spacer-po-gorach.jpg
Pierwszy adres dotyczy strony załącznika, jeśli witryna udostępnia takie strony. Drugi prowadzi bezpośrednio do pliku graficznego.
Z punktu widzenia optymalizacji obrazów ważniejsze są odpowiednia nazwa fizycznego pliku, tekst alternatywny ALT, kontekst wykorzystania zdjęcia, format oraz rozmiar obrazu.
Warto również sprawdzić, jak wtyczka SEO obsługuje strony załączników. Niektóre konfiguracje przekierowują je do plików multimedialnych lub innych adresów.
Sama obecność liczbowej końcówki nie jest jednak błędem SEO.
Dlaczego ponowne wgrywanie zdjęcia nie zawsze zmienia numerację?
Nasz eksperyment pokazał, że usunięcie zdjęcia i ponowne przesłanie go pod tą samą nazwą nie spowodowało zwiększenia końcówki z -4 na -5.
WordPress ponownie nadał -4, ponieważ wcześniejsze warianty pozostawały zajęte.
Oznacza to, że końcówka nie jest licznikiem kolejnych przesłań zdjęcia.
Jest rezultatem sprawdzania dostępności slugu w momencie tworzenia rekordu załącznika.
Nie należy jednak traktować usuwania i ponownego wgrywania zdjęć jako uniwersalnej metody aktualizacji grafik. Nowo przesłany plik otrzymuje nowy identyfikator załącznika, co może mieć znaczenie dla obrazów wyróżniających, galerii oraz innych powiązań.
Jeżeli chcemy jedynie podmienić zawartość zdjęcia, warto rozważyć narzędzie pozwalające zastąpić istniejący plik z zachowaniem jego identyfikatora.
Osobną kwestią jest pamięć podręczna przeglądarki, serwera lub CDN. Podmiana pliku pod tym samym adresem może powodować, że użytkownicy przez pewien czas nadal widzą jego starszą wersję.
Wnioski: problem nie dotyczył duplikatów zdjęć
Cała historia rozpoczęła się od jednego zdjęcia, które otrzymywało odnośnik zakończony na -4, mimo że w bibliotece mediów nie istniały inne pliki o tej samej nazwie.
Początkowo podejrzewaliśmy błąd WordPressa, nieprawidłowe usuwanie załączników, pozostałości w bazie danych oraz problem z wtyczką do zmiany nazw zdjęć.
Dopiero analiza tabeli wp_posts ujawniła, że trzy wcześniejsze warianty slugu były zajęte przez elementy menu.
Kolejne przypadki pokazały, że podobny konflikt może wystąpić również między artykułem a zdjęciem oraz między załącznikami mającymi identyczną nazwę podstawową, ale różne rozszerzenia.
Najważniejsze jest jednak to, że WordPress może dodawać końcówki liczbowe do adresów zdjęć nawet wtedy, gdy w bibliotece mediów nie ma żadnych duplikatów.
System nie sprawdza wyłącznie nazw fizycznych plików. Uwzględnia również slugi innych rekordów zapisanych w bazie danych.
Dlatego przed instalowaniem kolejnych wtyczek, ręczną zmianą nazw czy usuwaniem załączników warto najpierw sprawdzić, co rzeczywiście zajmuje wybrany slug.
Czasami wystarczy jedno zapytanie SQL, aby przekonać się, że pozorny błąd jest po prostu prawidłowym działaniem WordPressa.
