Rozrost wtyczek: gdy build AI zostawia cię z czterdziestoma aktywnymi wtyczkami

#Gdy lista wtyczek jest dłuższa niż mapa strony

Jeśli build dostarczył też własny PHP od asystenta AI, połącz ten audyt z audytem kodu wtyczek WordPress generowanych przez AI. Gdy rozrost, własny kod i spadek ruchu się sumują, praca wpada w naprawę stron zrobionych przez AI.

#Zanonimizowany case: 38 wtyczek, TTFB 1,47 s

Strona usług B2B (szkolenia i doradztwo dla branż regulowanych na polskim rynku) trafiła do nas po tym, jak ktoś z wewnątrz firmy odpalił Lighthouse i zapytał, czemu „WordPress jest taki ciężki”. Stronę składano przez około trzy tygodnie w Cursorze i ChatGPT: struktura podstron, szkice tekstów, formularze i typowe „zainstaluj coś do tego” z repozytorium wtyczek. Nikt nie był właścicielem listy wtyczek.

Hosting się nie zmienił: VPS 2 vCPU u polskiego dostawcy, PHP 8.2, bez object cache na wejściu. Redis dołożyliśmy po passie wtyczkowym i zdjął jeszcze około 120 ms z TTFB, ale większość zysku przyszła z usuwania i scalania wtyczek, nie z wymiany infrastruktury.

Pierwsza reakcja klienta była przewidywalna: „Przecież dodawaliśmy tylko to, co trzeba.” Tak właśnie wygląda rozrost. Każda instalacja miała sensowny powód. Koszt był skumulowany.

#Jak buildy z AI dochodzą do 40 wtyczek szybciej niż ręczne

Ręczny rozrost zwykle trwa miesiące: freelancer dokłada slider, marketing popup, ktoś instaluje drugą wtyczkę SEO „na próbę”. Przy AI ten sam mechanizm ściska się do dni, bo model optymalizuje wiarygodne domknięcie zadania, a nie spójność stosu.

Powtarzalne wzorce na intake rescue:

1. Jeden prompt, jedna wtyczka. Asystent nie mówi „rozszerz istniejącą wtyczkę formularzy”. Zwraca slug.
2. Brak pamięci inwentarza. Druga sesja nie wie, że w pierwszej poszedł Rank Math; w czwartej ktoś prosi o Yoast „pod lepsze schema”.
3. Układanie tutoriali. Model widział listy „najlepsze wtyczki do X” z blogów i YouTube. Build dziedziczy całą listę.
4. Własny kod plus komercyjny rozrost. Ten sam asystent, który zaproponował dwanaście wtyczek, wygenerował też trzy małe pliki w mu-plugins jako „szybkie poprawki”.
5. Wtyczki optymalizujące jako plaster. Gdy TTFB rośnie, kolejny prompt to „zainstaluj cache”, czasem bez wyłączenia pierwszego cache.

To nie wymaga złej woli. Wymaga luki procesowej: nikt z odpowiedzialnością za architekturę WordPressa nie przejrzał stosu przed launch.

#Osiem kategorii, które przebijają się przy buildach z AI

Na zanonimizowanej stronie te osiem kubełków odpowiadało za 31 z 38 wtyczek. Twoja lista będzie inna, ale kategorie wracają na rescue.

#1. Zdublowane SEO i schema

Dwie wtyczki SEO były aktywne jednocześnie. Obie wypuszczały schema. Obie wisiały na wp_head. Jedna została po migracji ze starego hostingu, druga z tygodnia buildu z AI. Zostaw jedną. Ustawienia scal ręcznie; automatyczne importery bez diff review zawodzą.

#2. Kilka kreatorów formularzy

Contact Form 7, kreator z promptu i lekka wtyczka modalna zbierały leady do różnych skrzynek. Po konsolidacji trzy formularze weszły do jednego narzędzia, reszta wyleciała.

#3. Konkurujące cache i „przyspieszacze”

Cache na poziomie hostingu i drugi „booster” minifikowały skrypty naraz. Na stronie cennika pojawiał się przerywany JavaScript. Nigdy dwa pełne warstwy HTML cache. Wybierz jeden system i skonfiguruj go.

#4. Analityka i piksele

Konektor GA, wtyczka piksela Facebooka, tag LinkedIn, trial heatmapy i GTM wstrzyknięty dwukrotnie (raz wtyczką, raz w nagłówku). Pomiar się nie poprawił. Waga żądań tak.

#5. Page builder i paczki dodatków

Elementor, płatna paczka addonów i legacy slider „na wszelki wypadek”. Strona główna na builderze; wewnętrzne podstrony nie. Część sekcji wyeksportowaliśmy jako statyczne bloki; slider usunięty.

#6. Duplikaty bezpieczeństwa i sprzątania

Dwa limitery logowania, menedżer plików (usunięty natychmiast) i „czyściciel bazy” odpalany przy każdym wejściu do admina. Bezpieczeństwo to świadomy stos, nie trzy nakładające się wtyczki.

#7. Narzędzia AI do treści i obrazów

Wtyczka pisząca teksty i auto-alt dokładały crona w adminie i wywołania API na zewnątrz. Workflow przeniesiony do redakcji; wtyczki wyszły.

#8. Własne mu-plugins od AI

Trzy pliki w mu-plugins/ z wklejonego PHP: własny redirect, „poprawka” uprawnień REST i kolumna w liście wpisów. Redirect dublował reguły z .htaccess. „Poprawka” REST wyłączyła integrację, której marketing używał codziennie. Po audycie bezpieczeństwa zostawiliśmy tylko kolumnę admina jako utrzymywany kod w jednym pliku; dwa pozostałe skasowane.

#Autodiagnostyka: sygnały, że jesteś głęboko w wtyczkach

Zrób to zanim zainstalujesz kolejny optimizer.

Query Monitor na stagingu (nie na produkcji, jeśli polityka zabrania), strona główna wylogowany, zrzut ekranu stosu zapytań. Ten jeden widok często wystarcza, żeby ktoś w firmie przejął odpowiedzialność za stos.

#Triaż: zostaw, scal, zastąp, usuń

Na każdym rescue rozrostu używamy czterokolumnowego rejestru. Każda aktywna wtyczka dostaje dokładnie jedną etykietę.

Zostaw - jeden właściciel funkcji, utrzymywana, bez nakładania. Np. jedna wtyczka SEO po scaleniu ustawień.

Scal - dwie wtyczki z sąsiednich zadań, które ogarnie jedno utrzymywane narzędzie. Np. trzy formularze w jeden.

Zastąp - rola sensowna, implementacja ciężka; kilka linii w child theme albo wzorzec blokowy. Np. wtyczka powiązanych wpisów z WP_Query na każdym view zastąpiona kuratorowanym blokiem.

Usuń - porzucona, zdublowana, niebezpieczna lub nieużywana. Menedżery plików, próbne SEO i „tymczasowe” debugi lądują tutaj.

Pracuj partiami po pięć do ośmiu wtyczek. Dezaktywuj, testuj formularze i checkout, mierz TTFB, potem kasuj. Masowe kasowanie psuje produkcję w piątek wieczorem.

Na zanonimizowanej stronie podział wyglądał tak:

• Zostaw: 21 wtyczek po konsolidacji (jedno SEO, jedne formularze, jeden cache, jeden pakiet bezpieczeństwa)
• Scal: 9 wtyczek wchłoniętych przez zostawione narzędzia
• Zastąp: 4 role przeniesione do motywu lub bloków
• Usuń: 8 wtyczek skasowanych (w tym 2 porzucone, 1 menedżer plików, 1 zdublowany cache)

#Własne wtyczki od AI to nadal wtyczki

Zespoły często liczą tylko wtyczki z katalogu i zapominają o mu-plugins albo wtyczkach „snippets”, które wstrzykują PHP. Asystenci AI chętnie je generują, bo to szybsze niż nauka poprawnej struktury wtyczki.

Każdy własny plik traktuj jak kod firm trzecich:

• Szukaj strażnika ABSPATH, nonce i $wpdb->prepare()
• Sprawdź, czy funkcja nie dubluje już aktywnej wtyczki
• Kod, który zostaje, trzymaj w repozytorium, nie w schowku w kokpicie

Gdy brakuje nonce i w SQL leci konkatenacja, przestań kasować komercyjne wtyczki, dopóki własny kod nie ma zakresu. Zły własny PHP plus kurczący się stos komercyjny potrafi odsłonić endpointy, o których nikt nie pamiętał.

#Workflow konsolidacji na stagingu

1. Zamroź nowe instalacje. Żadnych odpowiedzi „zainstaluj wtyczkę”, dopóki nie ma rejestru.
2. Wyeksportuj aktywną listę do arkusza: slug, wersja, data ostatniej aktualizacji, deklarowana rola, realna rola.
3. Oznacz nakładanie w SEO, cache, formularzach, analityce i bezpieczeństwie jako pierwsze.
4. Dezaktywuj duplikaty na stagingu, wyczyść cache, przetestuj ścieżki konwersji.
5. Zmierz TTFB i liczbę zapytań na stronie głównej, najcięższym landingu i stronie podziękowania formularza.
6. Kasuj małymi partiami, mierz po każdej.
7. Udokumentuj finalny stos w README projektu albo protokole przekazania, żeby następna sesja AI miała inwentarz do przeczytania.

Wycena rescue jest zawsze indywidualna, bo sama liczba wtyczek to tylko jeden parametr. Rozmiar bazy, własny kod AI i ruch mają równy ciężar.

#Czego nie robić

• Nie instaluj „menedżera wtyczek”, żeby naprawić rozrost. Dokładasz kolejną wtyczkę.
• Nie włączaj dwóch pełnych cache „dla pewności”.
• Nie pozwól AI wygenerować skryptu masowego kasowania wierszy w wp_options bez kopii i diff review.
• Nie zakładaj, że nieaktywne wtyczki są nieszkodliwe. Część ładuje kod na init w dziwnych stanach; po weryfikacji kasuj.
• Nie pomijaj testów formularzy pod pretekstem „to tylko blog”. Na case z tego artykułu zepsuty JavaScript siedział na cenniku, nie na liście wpisów.

#Kiedy eskalować do rescue

Przyrostowe sprzątanie działa, gdy nakładanie jest oczywiste, własnego kodu mało i ktoś techniczny trzyma staging. Eskaluj do formalnej naprawy stron zrobionych przez AI, gdy:

• Po pierwszym passie zostaje powyżej trzydziestek aktywnych wtyczek
• Kilka własnych wtyczek AI dotyka logowania, uploadów lub SQL
• TTFB bez cache zostaje powyżej około 1 s po usunięciu zdublowanego cache i SEO
• Firma nie może sobie pozwolić na zepsuty formularz lub płatność przy samodzielnym kasowaniu
• Skan bezpieczeństwa pokazuje znane CVE na porzuconych wtyczkach, których nikt nie zaktualizuje

Rescue to nie eufemizm na przebudowę. W case powyżej 17 wtyczek opuściło stos, motyw i tier hostingu zostały. Deliverable to zmierzony rejestr, nie pitch na nową platformę.

#Mierzenie sukcesu poza liczbą wtyczek

Liczba wtyczek to proxy. Śledź metryki, które czują użytkownicy:

Po konsolidacji ustaw budżet wtyczkowy: w tej klasie strony nowa wtyczka tylko wtedy, gdy wycofasz lub scalisz istniejącą. Wpisz tę regułę w pliku instrukcji projektu dla asystenta AI, żeby kolejny prompt nie cofnął rescue w jedno popołudnie.

#Słowniczek

• Plugin sprawl / rozrost wtyczek - gromadzenie aktywnych wtyczek z nakładającymi się rolami, aż spadają wydajność, bezpieczeństwo i utrzymanie.
• TTFB (Time to First Byte) - czas odpowiedzi serwera zanim przeglądarka zacznie render; wrażliwy na liczbę hooków PHP i zapytań do bazy.
• mu-plugin - wtyczka must-use ładowana przy każdym żądaniu z wp-content/mu-plugins/; często tam lądują „szybkie poprawki” od AI.
• Autoload opcji - opcje WordPressa ładowane przy każdym żądaniu; rozdmuchiwane przez wtyczki trzymające duże tablice z autoload=yes.
• Rozrost zapytań - nadmierna liczba zapytań SQL na odsłonę, typowa gdy wiele wtyczek niezależnie ciągnie metadane.

#Wniosek

Czterdzieści aktywnych wtyczek to nie wstyd. To efekt, gdy szybkie składanie z AI wyprzedza przegląd architektury. Zanonimizowana strona z tego przewodnika przeszła z 38 do 21 aktywnych wtyczek, mediana TTFB bez cache z 1,47 s do 0,68 s, zapytania na stronie głównej z 187 do 94 bez zmiany hostingu i bez przebudowy motywu. Praca była żmudna, mierzalna i w większości to odinstalowania.

Zacznij od rejestru, wyłącz zdublowane warstwy SEO i cache, audytuj własne pliki AI zanim pochwalisz się kasowaniem komercyjnych wtyczek, i mierz po każdej partii. Jeśli stos dalej walczy, do tego jest naprawa stron zrobionych przez AI: jawny podział zostaw-przepisz-usuń z liczbami, a nie kolejna rekomendacja wtyczki.