IT | Wordpress | Woocommerce | Blog Luckadomena.pl

Blog

  • Własny motyw WordPress czy page builder? Jak wybieram przy stronach firmowych

    Własny motyw WordPress czy page builder? Jak wybieram przy stronach firmowych

    Przy stronach firmowych na WordPressie prędzej czy później pada pytanie: budujemy na page builderze typu Elementor czy na własnym motywie? Ostatnio przygotowuję stronę dla warsztatu blacharsko-lakierniczego właśnie na własnym motywie, ale nie uważam, że to zawsze najlepszy wybór. W tym wpisie porównuję oba podejścia z perspektywy osoby, która robiła strony na jeden i drugi sposób.

    Page builder – zalety, których nie warto lekceważyć

    • Szybki start. Gotowe sekcje i szablony pozwalają postawić stronę w kilka dni.
    • Samodzielność klienta. Właściciel firmy może sam przestawić sekcję, podmienić zdjęcie czy dodać nową podstronę bez wzywania dewelopera.
    • Niższy koszt na starcie. Mniej godzin programisty to mniejsza faktura na początku współpracy.

    Dla małej firmy, która chce szybko być online i sama dbać o treści, to często rozsądny wybór.

    Gdzie page builder zaczyna przeszkadzać

    • Wydajność. Page buildery ładują dużo własnych stylów i skryptów, a każda sekcja to kilka zagnieżdżonych elementów HTML. Przekłada się to na wolniejsze ładowanie, szczególnie na telefonach, i słabsze wyniki Core Web Vitals.
    • Zależność od jednej wtyczki. Treść jest zapisana w formacie buildera. Zmiana narzędzia w przyszłości oznacza w praktyce przebudowę strony.
    • Brak spójności. Gdy każdy może ustawić inny odstęp, kolor i rozmiar czcionki, po roku strona wygląda jak składanka.
    • Więcej wtyczek, więcej aktualizacji. Dodatki do buildera to kolejne elementy, które trzeba aktualizować i które mogą się ze sobą gryźć.

    Własny motyw – co zyskujesz

    Lekki, czysty kod

    Ładujesz tylko te style i skrypty, których strona naprawdę potrzebuje. Przy dobrze zbudowanym motywie wysokie wyniki w PageSpeed Insights osiąga się bez dodatkowych wtyczek optymalizacyjnych.

    Pełna kontrola nad SEO i dostępnością

    Sam decydujesz o strukturze nagłówków, semantycznym HTML-u, danych strukturalnych i atrybutach dostępności. Nie walczysz z kodem generowanym przez narzędzie.

    Spójny system projektowy

    Kolory, typografia i odstępy są zdefiniowane w jednym miejscu. Każda nowa podstrona automatycznie wygląda tak samo dobrze jak pozostałe.

    Bezpieczeństwo i łatwiejsze utrzymanie

    Mniej wtyczek to mniej potencjalnych luk i mniej konfliktów przy aktualizacjach. Kod motywu można trzymać w repozytorium Git i wdrażać zmiany w kontrolowany sposób.

    A co z samodzielną edycją treści?

    To najczęstszy argument przeciwko własnemu motywowi – i da się go rozwiązać. Zamiast pozwalać na dowolne układanie elementów, przygotowuję gotowe, zaprojektowane bloki: sekcję usług, galerię realizacji, opinie klientów, FAQ, wezwanie do kontaktu. Klient wypełnia je treścią w edytorze blokowym WordPressa lub w polach przygotowanych np. w ACF. Ma swobodę w zakresie treści, ale nie zepsuje wyglądu strony.

    Jak wybieram w praktyce

    Page builder wybiorę, gdy:

    • budżet i czas są bardzo ograniczone,
    • klient chce często i samodzielnie zmieniać układ podstron, np. pod kampanie,
    • strona ma charakter tymczasowy albo testowy.

    Własny motyw wybiorę, gdy:

    • strona ma pracować na pozyskiwanie klientów z Google przez lata,
    • liczy się wydajność, szczególnie na telefonach,
    • firma ma określoną identyfikację wizualną, którą trzeba konsekwentnie utrzymać,
    • planowana jest dalsza rozbudowa, np. o sklep lub integracje.

    Podsumowanie

    Page builder i własny motyw to narzędzia do różnych zadań. Builder wygrywa szybkością startu i swobodą edycji, własny motyw – wydajnością, spójnością i długoterminowym kosztem utrzymania. Dla firm, dla których strona jest głównym źródłem zapytań od klientów, coraz częściej wybieram własny motyw z gotowymi blokami do edycji treści – to połączenie szybkości strony z wygodą dla klienta.

  • Nie potrzebujesz useEffect – 3 poprawki, które zrobiłem w kodzie swojego portfolio

    Nie potrzebujesz useEffect – 3 poprawki, które zrobiłem w kodzie swojego portfolio

    Przy porządkowaniu kodu mojego portfolio przed publikacją linter zgłosił ten sam błąd w trzech różnych komponentach: „Calling setState synchronously within an effect can trigger cascading renders”. Kod działał, strona wyglądała dobrze – a mimo to wszystkie trzy przypadki były do poprawy. W tym wpisie pokazuję, co było nie tak, jak to naprawiłem i czego nauczyło mnie to o useEffect.

    Do czego naprawdę służy useEffect?

    useEffect służy do synchronizacji komponentu z czymś spoza Reacta: timerem, subskrypcją zdarzeń, ręczną zmianą DOM, zewnętrzną biblioteką. Nie służy do wyliczania stanu z innego stanu ani do „ustawienia czegoś zaraz po pierwszym renderze”. Gdy w efekcie od razu wywołujemy setState, React renderuje komponent, uruchamia efekt, a potem musi wyrenderować go jeszcze raz. To niepotrzebna praca, a czasem widoczne mignięcie złej wartości.

    Przypadek 1: flaga isMounted

    Popularny wzorzec wyglądał tak:

    const [isMounted, setIsMounted] = useState(false)

useEffect(() => {
  setIsMounted(true)
}, [])

    Chodzi o to, żeby wiedzieć, czy kod działa już w przeglądarce, i uniknąć błędu hydracji – sytuacji, w której HTML wygenerowany na serwerze różni się od pierwszego renderu po stronie klienta. React ma do tego lepsze narzędzie: useSyncExternalStore, który przyjmuje osobną wartość dla serwera i dla przeglądarki.

    const subscribe = () => () => {}

export function useIsClient() {
  return useSyncExternalStore(subscribe, () => true, () => false)
}

    Przypadek 2: odczyt z localStorage

    Wybrany język strony i ustawienia dostępności zapisywałem w localStorage, a przy starcie kopiowałem je do stanu komponentu w efekcie. Problem polegał na tym, że ta sama informacja istniała w dwóch miejscach: w przeglądarce i w stanie Reacta. Rozwiązaniem było potraktowanie localStorage jako zewnętrznego magazynu danych i odczytywanie go przez useSyncExternalStore:

    const storedLocale = useLocalStorageItem('site-locale')
const locale = normalizeLocale(storedLocale)

    Język jest teraz wyliczany, a nie kopiowany. Jest jedno źródło prawdy, wszystkie komponenty czytające ten klucz są zsynchronizowane – także między kartami przeglądarki – a flaga isMounted stała się zbędna.

    Przypadek 3: animacja pisania tekstu

    Komponent wyświetlający kolejne słowa litera po literze miał trzy osobne stany: indeks słowa, liczbę widocznych znaków i informację, czy tekst jest właśnie kasowany. Większość zmian odbywała się w timerze, ale przejście do następnego słowa działo się bezpośrednio w efekcie. Głębsza przyczyna była taka, że trzy stany opisywały jedną rzecz – fazę animacji.

    Przepisałem go na mały automat stanów z useReducer. Faza jest jedna: pisanie, pauza albo kasowanie, a cała logika przejść siedzi w czystej funkcji:

    function advanceRotator(state, { activeWordLength, wordCount }) {
  switch (state.phase) {
    case 'typing':
      // add one character, switch to 'holding' when the word is complete
    case 'holding':
      return { ...state, phase: 'deleting' }
    case 'deleting':
      // remove one character, move to the next word at the end
  }
}

    Efekt robi teraz tylko jedno: ustawia timer, który wywołuje dispatch, i sprząta go w funkcji czyszczącej. Nie da się też uzyskać nielogicznej kombinacji stanów, która wcześniej była teoretycznie możliwa.

    Czego się nauczyłem

    • Zanim napiszesz useEffect, zapytaj: z czym się synchronizuję? Jeśli odpowiedź brzmi „z niczym spoza Reacta”, prawdopodobnie efekt nie jest potrzebny.
    • Nie kopiuj danych do stanu, jeśli możesz je wyliczyć. Jedno źródło prawdy eliminuje całą klasę błędów z rozjechanymi wartościami.
    • Kilka powiązanych stanów to sygnał do useReducer. Jawne fazy i czysta funkcja przejść są czytelniejsze i łatwiejsze do przetestowania.
    • Dane z zewnętrznych źródeł czytaj przez useSyncExternalStore. Rozwiązuje problem hydracji bez obejść w postaci flag.
    • Linter to sojusznik, nie przeszkoda. Reguły z React 19 wyłapały problemy, których nie widać w działaniu strony, a które z czasem prowadzą do trudnych do znalezienia błędów.

    Podsumowanie

    Wszystkie trzy komponenty działały przed poprawkami – i to jest najciekawsza lekcja. Kod, który „działa”, nie zawsze jest kodem dobrym. Po zmianach komponenty są prostsze, mają mniej stanu, renderują się rzadziej, a ich logika jest jawna. Jeśli Twój linter zgłasza set-state-in-effect, potraktuj to jako zaproszenie do uproszczenia kodu, a nie przeszkodę do wyciszenia.

  • Dane strukturalne schema.org – co dają i jak je wdrożyć na stronie, w sklepie i na blogu

    Dane strukturalne schema.org – co dają i jak je wdrożyć na stronie, w sklepie i na blogu

    Gwiazdki z ocenami pod wynikiem, cena i dostępność produktu, nazwa autora i data wpisu – takie dodatki w wynikach Google to często zasługa danych strukturalnych. W tym wpisie wyjaśniam, czym są, które typy faktycznie mają sens na stronie firmowej, w sklepie i na blogu, oraz jak je wdrożyć i sprawdzić.

    Czym są dane strukturalne?

    To dodatkowe informacje w kodzie strony, zapisane według słownika schema.org, które mówią wyszukiwarce wprost: „to jest produkt, kosztuje tyle, jest dostępny” albo „to jest firma, ma taki adres i takie godziny otwarcia”. Człowiek widzi te informacje na stronie, a dane strukturalne podają je maszynie w jednoznacznym formacie.

    Google zaleca format JSON-LD – osobny skrypt w kodzie strony, niezależny od HTML-a. Jest najłatwiejszy w utrzymaniu, bo nie trzeba przeplatać atrybutów z kodem szablonu.

    Przykład: dane strukturalne wpisu na blogu

    <script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Dane strukturalne schema.org – co dają i jak je wdrożyć",
  "datePublished": "2026-10-30",
  "author": {
    "@type": "Person",
    "name": "Imię Nazwisko",
    "url": "https://luckadomena.pl"
  }
}
</script>

    Które typy mają sens w praktyce

    Strona firmowa: Organization i LocalBusiness

    Dla firmy działającej lokalnie LocalBusiness (lub dokładniejszy typ, jeśli istnieje dla danej branży) pozwala opisać nazwę, adres, telefon, godziny otwarcia i obszar działania. Dla firmy bez siedziby dla klientów wystarczy Organization z logo i danymi kontaktowymi.

    Sklep: Product z ofertą

    Typ Product z obiektem Offer opisuje nazwę, cenę, walutę i dostępność. To jeden z typów, które najczęściej przekładają się na rozszerzony wygląd wyniku. WooCommerce generuje podstawowe dane produktu automatycznie, ale warto sprawdzić, czy są kompletne – np. czy zawierają markę i kod GTIN.

    Blog: Article lub BlogPosting

    Pomaga Google prawidłowo odczytać tytuł, datę publikacji i aktualizacji oraz autora. Przy treściach eksperckich wyraźnie wskazany autor z linkiem do strony o nim ma dodatkową wartość.

    Portfolio: Person

    Na stronie osobistej typ Person z imieniem, zawodem i linkami do profili (GitHub, LinkedIn) w polu sameAs pomaga powiązać stronę z Twoimi profilami w sieci.

    Ścieżka nawigacji: BreadcrumbList

    Prosty i przydatny typ, który pokazuje strukturę strony, np. Strona główna › Blog › Nazwa wpisu.

    Uczciwie o oczekiwaniach

    • Dane strukturalne nie są bezpośrednim czynnikiem rankingowym. Pomagają Google zrozumieć stronę i mogą wpłynąć na wygląd wyniku, a przez to na CTR.
    • Nie każdy typ daje wyniki rozszerzone. Google co jakiś czas zmienia, które dane wyświetla – np. wyniki FAQ są dziś pokazywane tylko dla wąskiej grupy stron. Zanim wdrożysz typ dla efektu wizualnego, sprawdź aktualną dokumentację Google.
    • Dane muszą zgadzać się z treścią strony. Oznaczanie informacji, których użytkownik nie widzi, albo wymyślonych opinii łamie wytyczne i może skończyć się ręcznym działaniem ze strony Google.

    Jak wdrożyć w WordPressie i w Next.js

    W klasycznym WordPressie podstawowe dane strukturalne generują popularne wtyczki SEO, a WooCommerce dodaje dane produktów. Warto jednak sprawdzić, co dokładnie trafia do kodu, bo kilka wtyczek naraz potrafi zdublować te same znaczniki.

    W Next.js (App Router) dane strukturalne dodaje się jako komponent renderujący tag <script type="application/ld+json"> z obiektem zbudowanym na podstawie danych strony – np. dla każdego wpisu pobranego z WordPressa przez REST API. Dzięki temu dane zawsze zgadzają się z treścią.

    Jak sprawdzić, czy działa

    1. Test wyników z elementami rozszerzonymi od Google – pokazuje, które typy zostały wykryte i czy kwalifikują się do wyników rozszerzonych.
    2. Walidator schema.org – sprawdza poprawność składni wszystkich typów, także tych, których Google nie wyświetla w specjalny sposób.
    3. Raporty w Google Search Console – po zaindeksowaniu pokazują błędy i ostrzeżenia dla całej witryny.

    Podsumowanie

    Dane strukturalne to niewielki nakład pracy z realnym potencjałem: lepiej zrozumiana strona, bogatsze wyniki wyszukiwania i wyższy CTR. Zacznij od podstaw – Organization lub LocalBusiness dla firmy, Product dla sklepu i BlogPosting dla wpisów – i pilnuj, żeby zawsze opisywały to, co użytkownik faktycznie widzi na stronie.

  • Lokalne SEO dla firmy usługowej – jak zdobywać klientów z Google w swoim mieście

    Lokalne SEO dla firmy usługowej – jak zdobywać klientów z Google w swoim mieście

    Warsztat, studio detailingu, gabinet, firma remontowa – dla lokalnej firmy usługowej najcenniejszy klient to ten, który wpisuje w Google „usługa + miasto” albo „usługa w pobliżu” i chce zadzwonić jeszcze dziś. Pracując przy stronach dla firm z Włocławka i okolic, widzę, że o tym, kto dostanie ten telefon, decyduje kilka podstawowych rzeczy. W tym wpisie opisuję, jak podchodzę do lokalnego SEO krok po kroku.

    Dwa miejsca, w których walczysz o klienta

    Przy lokalnych zapytaniach Google pokazuje zwykle dwa rodzaje wyników:

    • Mapę z wizytówkami firm – tu decyduje przede wszystkim profil firmy w Google,
    • klasyczne wyniki wyszukiwania – tu liczy się Twoja strona internetowa.

    Najlepsze efekty daje praca nad obydwoma jednocześnie, bo wzajemnie się wspierają.

    Krok 1: Profil Firmy w Google

    To absolutna podstawa i często największy szybki zysk. Zadbaj o to, żeby profil był kompletny:

    • Główna kategoria dobrana możliwie precyzyjnie – to jeden z najważniejszych elementów profilu,
    • usługi z krótkimi opisami,
    • aktualne godziny otwarcia, telefon i link do strony,
    • prawdziwe zdjęcia – realizacje, wnętrze, zespół, a nie zdjęcia stockowe,
    • regularne odpowiadanie na opinie, także te negatywne – rzeczowo i bez emocji.

    Opinie mają ogromny wpływ zarówno na widoczność, jak i na decyzję klienta. Najprostszy sposób na ich zbieranie to poprosić zadowolonego klienta od razu po usłudze i wysłać mu bezpośredni link do wystawienia opinii.

    Krok 2: Spójne dane firmy (NAP)

    NAP to nazwa, adres i telefon (ang. Name, Address, Phone). Muszą być identyczne na stronie, w profilu Google, w katalogach firm i na profilach społecznościowych. Rozbieżności – inny numer telefonu, stara nazwa ulicy, różne zapisy nazwy firmy – utrudniają Google powiązanie tych informacji z jedną firmą.

    Krok 3: Strona zbudowana pod usługi i lokalizację

    Najczęstszy błąd, jaki widzę: jedna podstrona „Oferta”, na której są wymienione wszystkie usługi w jednym akapicie. Google nie ma wtedy czego pokazać na konkretne zapytanie. Lepsza struktura to:

    • osobna podstrona dla każdej głównej usługi – np. osobno folia ochronna PPF, osobno powłoka ceramiczna,
    • w tytule i nagłówku nazwa usługi oraz miasta, np. „Powłoka ceramiczna – Włocławek”,
    • konkretny opis: na czym polega usługa, ile trwa, od czego zależy cena, czego klient może się spodziewać,
    • zdjęcia własnych realizacji i krótkie FAQ z pytaniami, które klienci naprawdę zadają,
    • wyraźny przycisk kontaktu – telefon klikany na telefonie komórkowym to podstawa.

    Krok 4: Dane strukturalne LocalBusiness

    Znaczniki schema.org typu LocalBusiness (lub bardziej szczegółowego typu, jeśli pasuje do branży) pomagają wyszukiwarce jednoznacznie odczytać nazwę firmy, adres, godziny otwarcia i telefon. To nie jest magiczny przycisk „wyżej w Google”, ale porządkuje informacje i ułatwia ich prawidłowe wyświetlanie.

    Krok 5: Wydajność na telefonie

    Większość lokalnych wyszukiwań odbywa się na smartfonie, często w drodze. Strona, która ładuje się kilka sekund, traci klienta, zanim ten zobaczy numer telefonu. Kompresja zdjęć, lekki motyw i ograniczenie zbędnych wtyczek to inwestycja, która zwraca się zarówno w SEO, jak i w liczbie telefonów.

    Jak mierzyć efekty

    • Statystyki Profilu Firmy – wyświetlenia, kliknięcia w telefon, prośby o trasę dojazdu,
    • Google Search Console – na jakie frazy z nazwą miasta wyświetla się strona i jaki ma CTR,
    • pomiar kliknięć w telefon i formularz w Google Analytics 4 – to są realne zapytania od klientów.

    Podsumowanie

    Lokalne SEO to nie jednorazowy trik, tylko porządek: kompletny profil firmy, spójne dane, osobne podstrony dla usług, opinie od prawdziwych klientów i szybka strona na telefonie. Małe firmy często mają tu przewagę nad dużymi graczami – bo mogą pokazać prawdziwe realizacje i prawdziwy kontakt z klientem z okolicy.

  • Testy E2E w Cypressie dla sklepu WooCommerce – jak upewnić się, że koszyk zawsze działa

    Sklep internetowy, w którym nie działa koszyk, przez kilka godzin nie zarabia ani złotówki – a właściciel często dowiaduje się o tym dopiero od klienta. Aktualizacja wtyczki, nowa wersja WooCommerce, zmiana motywu – każda z tych rzeczy może po cichu zepsuć ścieżkę zakupu. Dlatego przy sklepach, nad którymi pracuję, stawiam na automatyczne testy end-to-end w Cypressie. W tym wpisie pokazuję, co warto testować i jak podejść do tego bez budowania wielkiego projektu QA.

    Czym są testy E2E i dlaczego akurat w sklepie?

    Testy end-to-end (E2E) symulują prawdziwego użytkownika: otwierają przeglądarkę, klikają w przyciski, wypełniają formularze i sprawdzają, czy strona zachowuje się zgodnie z oczekiwaniami. W sklepie WooCommerce najważniejsza jest jedna rzecz – czy klient jest w stanie kupić produkt. Test E2E sprawdza dokładnie to, niezależnie od tego, która wtyczka czy fragment kodu odpowiada za poszczególne kroki.

    Co testować w pierwszej kolejności

    Nie trzeba od razu pokrywać testami całego sklepu. Zacznij od ścieżek, które bezpośrednio wpływają na sprzedaż:

    1. Strona główna i kategoria – czy się ładują i czy wyświetlają produkty.
    2. Dodanie produktu do koszyka – także produktu z wariantami, np. z wyborem rozmiaru.
    3. Koszyk – zmiana ilości, usunięcie produktu, poprawne przeliczenie sumy.
    4. Kod rabatowy – czy działa poprawny kod i czy błędny zwraca komunikat.
    5. Zamówienie – przejście przez checkout aż do strony z podziękowaniem.
    6. Formularz kontaktowy i logowanie – jeśli sklep z nich korzysta.

    Przykładowy test: dodanie produktu do koszyka

    describe('Cart', () => {
  it('adds a product to the cart', () => {
    cy.visit('/sklep/')
    cy.get('[data-cy=product-card]').first().click()
    cy.get('[data-cy=add-to-cart]').click()

    cy.visit('/koszyk/')
    cy.get('[data-cy=cart-item]').should('have.length', 1)
  })
})

    Zwróć uwagę na atrybuty data-cy. Zamiast polegać na klasach CSS, które zmieniają się przy każdej aktualizacji motywu, dodaję do kluczowych elementów stabilne atrybuty przeznaczone wyłącznie do testów. Dzięki temu zmiana wyglądu nie psuje testów, a test psuje się tylko wtedy, gdy naprawdę zepsuje się funkcja.

    Zasady, które oszczędzają nerwów

    Testuj na kopii sklepu, nie na produkcji

    Test, który składa zamówienie, tworzy prawdziwe zamówienie w bazie, wysyła maile i zmienia stany magazynowe. Dlatego testy uruchamiam na środowisku testowym (stagingu) z włączoną testową metodą płatności, np. płatnością przy odbiorze. Na produkcji wystarczą testy „tylko do odczytu”: czy strony się ładują i czy kluczowe elementy są widoczne.

    Nie czekaj „na sztywno”

    Komendy w stylu cy.wait(3000) spowalniają testy i i tak bywają zawodne. WooCommerce dodaje produkty do koszyka zapytaniami AJAX, więc lepiej przechwycić takie zapytanie przez cy.intercept() i poczekać dokładnie na jego zakończenie.

    Każdy test niezależny

    Test nie powinien zakładać, że poprzedni zostawił coś w koszyku. Każdy zaczyna od czystego stanu – dzięki temu wynik jest powtarzalny, a błąd łatwo zlokalizować.

    Kiedy uruchamiać testy

    • Po każdej aktualizacji WordPressa, WooCommerce, wtyczek lub motywu – najpierw na stagingu, potem dopiero na produkcji.
    • Po zmianach w kodzie – najlepiej automatycznie, przy każdym pushu do repozytorium (np. przez GitHub Actions).
    • Cyklicznie – prosty test „czy sklep żyje” uruchamiany codziennie potrafi wyłapać problem, zanim zauważy go klient.

    Podsumowanie

    Testy E2E w Cypressie nie są zarezerwowane dla dużych firm. Kilka dobrze dobranych scenariuszy – koszyk, kupon, zamówienie – daje właścicielowi sklepu spokój przy każdej aktualizacji, a deweloperowi pewność, że jego zmiana niczego nie zepsuła. Zacznij od jednego testu najważniejszej ścieżki zakupowej i rozbudowuj zestaw stopniowo.

  • Google for WooCommerce – dlaczego warto podpiąć sklep i jak uniknąć odrzuconych produktów

    Jeśli prowadzisz sklep na WooCommerce i Twoje produkty nie pojawiają się w Google Zakupach, tracisz ruch, który może być całkowicie darmowy. Oficjalna wtyczka Google for WooCommerce łączy sklep z Google Merchant Center i automatycznie przesyła do Google informacje o produktach. W tym wpisie wyjaśniam, dlaczego warto ją podpiąć, jak przygotować sklep, żeby produkty nie zostały odrzucone, i na co uważać przy konfiguracji.

    Co daje Google for WooCommerce?

    • Bezpłatne informacje o produktach. Twoje produkty mogą wyświetlać się w zakładce Zakupy i innych miejscach w Google bez płacenia za kliknięcia.
    • Automatyczną synchronizację. Ceny, dostępność i nowe produkty aktualizują się w Merchant Center same – bez ręcznego generowania pliku XML.
    • Kampanie reklamowe z poziomu panelu. Gdy będziesz gotowy na płatną promocję, kampanię Performance Max uruchomisz bezpośrednio z WooCommerce.
    • Jedno miejsce do zarządzania. Błędy produktów i status zatwierdzenia widzisz w panelu sklepu, a nie tylko w osobnym narzędziu Google.

    Dla małego sklepu sam darmowy ruch z bezpłatnych informacji o produktach często jest wystarczającym powodem, żeby poświęcić na konfigurację jedno popołudnie.

    Zanim podepniesz: checklista sklepu

    Większość problemów z Merchant Center bierze się nie z wtyczki, tylko z braków w samym sklepie. Zanim połączysz konta, sprawdź:

    • Dane kontaktowe – adres, e-mail lub telefon widoczne na stronie.
    • Regulamin i polityka zwrotów – opublikowane i łatwo dostępne, najlepiej w stopce.
    • Koszty dostawy – jasno opisane i zgodne z tym, co skonfigurujesz w Merchant Center.
    • HTTPS w całym sklepie, łącznie z koszykiem i zamówieniem.
    • Ceny brutto – takie same na karcie produktu, w koszyku i w danych przesyłanych do Google.
    • Zdjęcia produktów – czyste, bez napisów promocyjnych, ramek i znaków wodnych.
    • Identyfikatory produktów – kod GTIN (EAN), jeśli produkt go ma, lub marka i numer katalogowy producenta.

    Najczęstsze powody odrzucenia produktów

    Niezgodna cena lub dostępność

    Google porównuje dane z feedu z tym, co widzi na stronie. Jeśli cena w feedzie różni się od ceny na karcie produktu, produkt zostanie odrzucony. Częste przyczyny to agresywny cache, promocje ustawione w inny sposób niż standardowa cena promocyjna WooCommerce albo wtyczki przeliczające ceny dopiero w przeglądarce.

    Brak identyfikatorów

    Produkty markowe bez GTIN mają ograniczoną widoczność. Warto uzupełnić kody EAN w danych produktu – wtyczka pozwala przypisać je do produktów i wariantów.

    Warianty produktów

    W sklepie odzieżowym jeden model koszulki to kilka rozmiarów i kolorów. Każdy wariant trafia do Google jako osobny produkt, więc każdy potrzebuje poprawnej ceny, dostępności i – najlepiej – własnego zdjęcia przy różnych kolorach.

    Zasady dotyczące określonych kategorii

    Niektóre rodzaje produktów, np. część chemii czy suplementy, podlegają dodatkowym zasadom reklamowym. Zanim zaczniesz, sprawdź w zasadach Merchant Center, czy Twój asortyment nie wymaga dodatkowych informacji lub nie jest ograniczony.

    Jak przebiega konfiguracja

    1. Instalujesz wtyczkę Google for WooCommerce i łączysz konto WordPress.com, Google oraz Merchant Center.
    2. Weryfikujesz i zgłaszasz własność domeny – wtyczka robi to w dużej mierze automatycznie.
    3. Wybierasz kraj docelowy, język i ustawienia wysyłki.
    4. Uruchamiasz synchronizację produktów i czekasz na weryfikację przez Google.
    5. Przeglądasz raport problemów i poprawiasz produkty z ostrzeżeniami lub odrzuceniami.

    Pierwsza weryfikacja może potrwać kilka dni. W tym czasie nie zmieniaj masowo cen ani struktury produktów – utrudnisz sobie diagnozę ewentualnych problemów.

    Nie zapomnij o pomiarze

    Ruch z Google Zakupów warto mierzyć od pierwszego dnia. Połącz sklep z Google Analytics 4 i skonfiguruj śledzenie konwersji, a jeśli planujesz reklamy – zadbaj o poprawnie wdrożony baner zgód z obsługą Consent Mode, który w Europejskim Obszarze Gospodarczym jest potrzebny do pełnego wykorzystania danych w reklamach Google. Bez pomiaru nie odpowiesz na najważniejsze pytanie: czy ten kanał sprzedaje.

    Podsumowanie

    Google for WooCommerce to jeden z najprostszych sposobów, żeby produkty z małego sklepu pojawiły się w Google bez budżetu reklamowego. Kluczem nie jest sama wtyczka, ale porządek w sklepie: kompletne dane kontaktowe i regulaminy, spójne ceny, dobre zdjęcia i identyfikatory produktów. Jeśli to przygotujesz przed podpięciem, większość produktów przejdzie weryfikację za pierwszym razem, a Ty zyskasz nowe, darmowe źródło ruchu.

  • Ahrefs czy Google Search Console? Kiedy płatne narzędzie SEO naprawdę się opłaca

    „Czy muszę płacić za Ahrefsa, żeby robić SEO?” – to jedno z pytań, które słyszę najczęściej od właścicieli małych sklepów i firm usługowych. Krótka odpowiedź: na start nie. Dłuższa: są sytuacje, w których płatne narzędzie oszczędza tygodnie pracy. W tym wpisie pokazuję, jak dzielę zadania między Google Search Console a Ahrefs i kiedy warto sięgnąć po każde z nich.

    Zawsze zaczynaj od Google Search Console

    Search Console jest darmowa i pokazuje prawdziwe dane z Google o Twojej stronie – nie szacunki. Znajdziesz w niej:

    • zapytania, na które wyświetla się Twoja strona, z liczbą kliknięć, wyświetleń, CTR i średnią pozycją,
    • stan indeksowania – które adresy są w indeksie, a które zostały pominięte i dlaczego,
    • raporty Core Web Vitals, czyli realną wydajność strony u użytkowników,
    • informacje o problemach z danymi strukturalnymi i bezpieczeństwem.

    Jeśli strona nie ma podpiętej Search Console, to pierwsza rzecz do zrobienia – przed jakimkolwiek płatnym narzędziem.

    Mój cotygodniowy workflow w Search Console

    1. Wysokie wyświetlenia, niski CTR. Filtruję strony, które Google często pokazuje, ale mało kto w nie klika. Zwykle winny jest nijaki tytuł albo opis meta. Przepisanie ich pod intencję wyszukiwania to najszybszy zysk w całym SEO.
    2. Frazy na pozycjach 8–20. To zapytania „prawie na pierwszej stronie”. Często wystarczy rozbudować treść o brakujący podtemat, dodać sekcję FAQ albo linki wewnętrzne z innych podstron.
    3. Raport indeksowania. Sprawdzam, czy ważne podstrony – kategorie sklepu, karty usług – nie wypadły z indeksu, i czy w indeksie nie ma śmieci, np. stron filtrów czy wyników wyszukiwania.

    Ten proces nie kosztuje nic, a przy stronach, które już mają trochę ruchu, potrafi dać więcej niż miesiące pisania nowych treści.

    Czego Search Console Ci nie powie

    Search Console pokazuje wyłącznie Twoją stronę i tylko zapytania, na które już się wyświetlasz. Nie dowiesz się z niej:

    • na jakie frazy pozycjonuje się konkurencja,
    • jakich tematów brakuje na Twojej stronie w porównaniu z innymi,
    • skąd konkurencja ma linki prowadzące do jej witryny,
    • jaki jest szacowany potencjał frazy, na którą jeszcze w ogóle się nie wyświetlasz.

    I tu zaczyna się rola narzędzi takich jak Ahrefs.

    Kiedy Ahrefs naprawdę się opłaca

    Przed startem nowej strony lub sklepu

    Nowa domena nie ma danych w Search Console, więc nie ma na czym pracować. Analiza konkurencji w Ahrefs pozwala z góry zaplanować strukturę kategorii i podstron pod frazy, których ludzie faktycznie szukają, zamiast zgadywać.

    Planowanie treści

    Funkcja porównania słów kluczowych z konkurencją (content gap) pokazuje frazy, na które pozycjonuje się kilka konkurencyjnych stron, a Twoja nie. To gotowa lista tematów na blog lub opisów kategorii.

    Analiza linków

    Gdy dwie strony mają porównywalną treść, o pozycji często decydują linki. Ahrefs pokazuje profil linków konkurencji – katalogi branżowe, lokalne portale, partnerów – co daje konkretne pomysły na własne działania.

    Audyt techniczny większej witryny

    Przy sklepie z setkami produktów ręczne szukanie zduplikowanych tytułów, błędów 404 czy łańcuchów przekierowań nie ma sensu. Crawler zrobi to w kilka minut.

    Darmowa opcja, o której mało kto wie

    Ahrefs udostępnia bezpłatne Ahrefs Webmaster Tools dla stron, których własność zweryfikujesz (np. przez Search Console). Dostajesz audyt techniczny i podgląd linków prowadzących do Twojej witryny. Nie przeanalizujesz w ten sposób konkurencji, ale do pilnowania własnej strony to bardzo dobre uzupełnienie Search Console.

    Pułapki przy korzystaniu z narzędzi SEO

    • Wolumeny są szacunkami. Szczególnie przy lokalnych, polskich frazach (np. z nazwą miasta) liczby mogą mocno odbiegać od rzeczywistości. Traktuj je jako wskazówkę do porównania fraz między sobą, a nie jako prognozę ruchu.
    • Metryki to nie cel. Wskaźniki typu Domain Rating to wewnętrzna miara narzędzia, nie czynnik rankingowy Google. Celem jest ruch i sprzedaż, nie ładniejsza liczba w raporcie.
    • Dane bez działania nic nie dają. Najlepszy raport jest wart tyle, ile zmian na stronie po nim wprowadzisz.

    Podsumowanie

    Search Console to fundament – darmowy, oparty na prawdziwych danych i wystarczający dla większości małych stron, które już mają ruch. Ahrefs (lub podobne narzędzie) warto włączyć, gdy startujesz z nową stroną, planujesz większą rozbudowę treści, analizujesz konkurencję albo audytujesz duży sklep. Najlepsze efekty daje połączenie obu: Ahrefs mówi, gdzie warto powalczyć, a Search Console pokazuje, czy to działa.

  • Headless WordPress z Next.js – kiedy ma sens, a kiedy to przerost formy

    Moje portfolio na luckadomena.pl działa w architekturze headless: WordPress pod adresem cms.luckadomena.pl służy wyłącznie do zarządzania treścią, a stronę, którą widzisz, generuje Next.js. Brzmi nowocześnie i takie jest, ale to nie jest rozwiązanie dla każdego projektu. W tym wpisie opisuję, kiedy headless WordPress ma sens, kiedy jest przerostem formy i jakie decyzje podjąłem przy własnej stronie.

    Czym jest headless WordPress?

    W klasycznym WordPressie jeden system robi wszystko: przechowuje treść, renderuje szablon PHP i wysyła gotowy HTML do przeglądarki. W podejściu headless „odcinamy głowę”, czyli warstwę prezentacji. WordPress zostaje panelem do pisania wpisów i udostępnia dane przez REST API (np. /wp-json/wp/v2/posts) albo GraphQL (wtyczka WPGraphQL). Frontend to osobna aplikacja, u mnie w Next.js, która te dane pobiera i sama decyduje, jak je wyświetlić.

    Kiedy headless WordPress ma sens

    • Chcesz pełnej kontroli nad frontendem. Żadnych ograniczeń motywu, żadnego page buildera – komponenty React, TypeScript i nowoczesne narzędzia.
    • Zależy Ci na wydajności. Strony można wygenerować z góry jako statyczny HTML, który ładuje się błyskawicznie i nie obciąża serwera przy każdym wejściu.
    • Bezpieczeństwo ma znaczenie. Panel WordPressa żyje na osobnej subdomenie, a publiczna strona to czyste pliki – nie ma tam PHP ani bazy danych, które można zaatakować.
    • Treść trafia w kilka miejsc. Te same dane z API może wykorzystać strona, aplikacja mobilna czy newsletter.
    • Redakcja zna WordPressa. Osoba pisząca treści dalej pracuje w znanym panelu, a deweloper ma swobodę po stronie frontendu.

    Kiedy to przerost formy

    • Klient chce sam układać strony w page builderze. Elementor czy Gutenberg z rozbudowanymi blokami tracą sens, bo frontend nie wie, jak je wyrenderować.
    • Projekt opiera się na wtyczkach działających na froncie. Formularze, koszyk WooCommerce, wtyczki SEO generujące meta tagi – w headless każdą z tych rzeczy trzeba zbudować lub podpiąć samodzielnie.
    • Mały budżet i brak dewelopera na stałe. Zamiast jednej aplikacji utrzymujesz dwie. Każda zmiana wyglądu to praca programisty, a nie kliknięcie w panelu.
    • Prosta wizytówka firmy. Dobrze zoptymalizowany klasyczny WordPress z lekkim motywem w zupełności wystarczy.

    Jak zrobiłem to w praktyce

    Najważniejsza decyzja dotyczyła sposobu renderowania. Next.js daje kilka możliwości:

    • SSG (Static Site Generation) – strony generowane raz, podczas budowania,
    • SSR (Server-Side Rendering) – strona generowana przy każdym wejściu, wymaga serwera Node.js,
    • ISR (Incremental Static Regeneration) – statyczne strony odświeżane w tle co określony czas, również wymaga serwera.

    Portfolio stoi na zwykłym hostingu współdzielonym, bez Node.js. Wybrałem więc pełny statyczny eksport: w konfiguracji ustawiam output: 'export', a podczas buildu Next.js pobiera z WordPressa wszystkie wpisy i dla każdego generuje osobny plik HTML. Listę adresów dostarcza funkcja generateStaticParams:

    export async function generateStaticParams() {
  const posts = await getPosts()
  return posts.map(post => ({ slug: post.slug }))
}

    Dodatkowo włączyłem trailingSlash: true. Każda podstrona zapisuje się wtedy jako blog/nazwa-wpisu/index.html, a serwer Apache serwuje ją bez żadnych reguł przepisywania adresów.

    Cena tego wyboru jest jasna: nowy wpis na blogu pojawia się na stronie dopiero po ponownym zbudowaniu i wgraniu plików. Przy portfolio, gdzie treść zmienia się rzadko, to rozsądny kompromis w zamian za szybkość, bezpieczeństwo i tani hosting.

    Pułapki, na które trzeba się przygotować

    SEO jest po Twojej stronie

    Wtyczka SEO w WordPressie nie wygeneruje meta tagów na froncie w Next.js. Tytuły, opisy, Open Graph, mapę witryny i robots.txt trzeba zbudować samodzielnie – na szczęście App Router ma do tego wbudowane API (metadata, generateMetadata, sitemap.ts).

    Pobieraj tylko potrzebne dane

    REST API WordPressa domyślnie zwraca bardzo dużo pól. Parametr _fields pozwala ograniczyć odpowiedź do tego, czego naprawdę używasz, np. ?_fields=slug,title,excerpt,date. Mniej danych to szybszy build.

    Hydracja i dane z przeglądarki

    Strona generowana na etapie buildu nie ma dostępu do window ani localStorage. Jeśli zapisujesz w przeglądarce np. wybrany język albo ustawienia dostępności, odczyt musi być zrobiony tak, aby pierwszy render po stronie klienta zgadzał się z HTML-em z buildu. Ja użyłem do tego hooka useSyncExternalStore, który ma osobną wartość dla serwera i dla przeglądarki.

    Obrazy

    Wbudowana optymalizacja obrazów w Next.js działa na serwerze, więc przy statycznym eksporcie trzeba ją wyłączyć (images.unoptimized) i zadbać o rozmiary oraz formaty plików już w WordPressie.

    Podsumowanie: krótka checklista decyzji

    • Czy potrzebujesz pełnej kontroli nad frontendem i wydajności na najwyższym poziomie? Headless ma sens.
    • Czy klient chce sam budować strony w page builderze i korzystać z wielu wtyczek frontowych? Zostań przy klasycznym WordPressie.
    • Czy masz hosting z Node.js? Jeśli nie, statyczny eksport to dobre wyjście – pod warunkiem, że akceptujesz ponowny build przy każdej zmianie treści.

    Headless WordPress to narzędzie, nie cel sam w sobie. W moim przypadku pozwolił połączyć wygodny panel do pisania z szybkim, nowoczesnym frontendem – i właśnie dlatego go wybrałem.

  • Jak przyspieszyć stronę na WordPressie?

    Jak przyspieszyć stronę na WordPressie?

    Szybkość strony wpływa na wygodę użytkowników, pozycję w Google oraz współczynnik konwersji. Optymalizację warto rozpocząć od pomiaru wydajności za pomocą narzędzi PageSpeed Insights lub GTmetrix.Najważniejsze działaniazoptymalizuj obrazy i używaj formatu WebP,włącz pamięć podręczną,usuń nieużywane wtyczki,wybierz szybki hosting,regularnie aktualizuj WordPressa.Nawet kilka prostych zmian może zauważalnie skrócić czas ładowania witryny.

  • 5 przydatnych wtyczek do WordPressa

    Wtyczki pozwalają szybko rozszerzyć możliwości WordPressa bez samodzielnego programowania. Nie należy jednak instalować ich zbyt wiele, ponieważ mogą obciążać stronę.Jak wybierać wtyczki?Przed instalacją sprawdź liczbę aktywnych instalacji, opinie użytkowników, częstotliwość aktualizacji oraz zgodność z używaną wersją WordPressa.Przydatne typy wtyczekwtyczka SEO,system kopii zapasowych,ochrona przed spamem,optymalizacja pamięci podręcznej,formularz kontaktowy.