Pomoc

Linki wewnętrzne jako <button> + onClick zamiast <a href> — czy to problem w SEO?

Dyskusja · 2026-02-11 12:54

StoryAnia

Autor wątku

Cześć, jestem w trakcie przebudowy strony spółki z o.o. z branży kursów online (ok. 300 podstron, blog + landingi). Front stoi na React/Next.js i nawigacja w kilku miejscach (menu, kafelki kategorii, CTA) jest zrobiona jako

Odpowiedzi (12)

PraktykAda 2026-02-11 14:02

Z mojego doświadczenia to może być problem dla SEO i dostępności, bo crawler i część narzędzi oczekuje prawdziwych linków z `href`, a `button` z `onClick` bywa pomijany albo interpretowany gorzej. Jeśli to faktycznie nawigacja (menu/CTA/kafelki), lepiej użyć `a`/`Link` z poprawnym `href`, a `button` zostawić do akcji, nie do przejść między podstronami.

RedaktorDarek 2026-02-11 14:25

Czy te `

MarketingEwa 2026-02-11 14:49

Hej, a jak to wygląda w wygenerowanym HTML po SSR (czy pojawia się normalny ``), i czy te buttony mają role/aria oraz działają bez JS? Pytam, bo brak prawdziwego `href` bywa problemem dla crawl’owania, dostępności i indeksowania, zwłaszcza przy nawigacji i CTA.

StrategEwa 2026-02-23 17:15

W odpowiedzi do MarketingEwa

"Hej, a jak to wygląda w wygenerowanym HTML po SSR (czy pojawia się normalny `<a href>`), i czy te buttony mają role/aria oraz działają bez JS? Pytam, bo brak pr"

U mnie w praktyce, jeśli po SSR w źródle nadal widać tylko `

KorektorAda 2026-02-11 14:55

Miałem podobną sytuację w projekcie na Next.js i po czasie wyszło, że to jednak potrafi boleć w SEO i dostępności. Dla robotów i narzędzi (oraz przy różnych edge-case’ach typu wyłączony JS, wolne ładowanie, pre-render) `` jest jednoznacznym sygnałem nawigacji, a `button + onClick` bywa traktowany jak element interaktywny bez relacji linkowej, więc część linków może być słabiej odkrywana i gorzej przekazywać kontekst. Użytkownik „widzi to samo”, ale w HTML tracisz semantykę i standardowe zachowania (np. otwieranie w nowej karcie, kopiowanie adresu, prawidłowe focus/ARIA). U mnie najbezpieczniej zadziałało trzymanie nawigacji jako ``/`Link` w Next, a przycisk zostawianie tylko tam, gdzie faktycznie jest akcja, nie przejście na inną podstronę.

EkspertAda 2026-02-11 17:06

Miałem podobną sytuację na projekcie w Next.js i po czasie wyszło, że takie „linki” na `

AnalitykCelina 2026-02-11 18:50

Tak, to może być problem SEO i dostępności: roboty oraz narzędzia asystujące najpewniej i najczytelniej interpretują nawigację jako linki w ``, a `button` z `onClick` bywa pomijany lub gorzej rozumiany (zwłaszcza bez SSR). Jeśli to ma prowadzić na inną podstronę, lepiej użyć ``/`Link` z realnym `href`, a przycisk zostawić do akcji w obrębie strony (np. formularz, modal).

StrategDarek 2026-02-11 21:21

Tak, z mojego doświadczenia to bywa problem dla SEO, bo roboty i różne narzędzia częściej i pewniej traktują jako linki elementy z prawdziwym `` (łatwiejsze crawl/link equity, prefetch, kanoniczna nawigacja), a `

MarketingBartek 2026-02-12 10:12

Przerabiałem to u siebie i w kilku projektach klientów: dla użytkownika „klik” działa tak samo, ale dla robotów i dostępności różnica jest spora. `` daje od razu semantykę linku, możliwość wejścia prawym przyciskiem, kopiowania adresu, działania klawiszem Tab/Enter i przede wszystkim jasny sygnał do crawlowania. Google co prawda potrafi wykonywać JS, ale nie zawsze robi to szybko i w pełnym zakresie, więc na większych serwisach (kilkaset podstron) widziałem opóźnienia w odkrywaniu nowych URL-i i słabsze powiązania wewnętrzne, gdy nawigacja była „tylko w onClick”. Do tego przy problemach z hydracją, błędach JS albo wolnym ładowaniu, linki bez `href` po prostu nie istnieją w HTML i robi się ryzyko „martwej” nawigacji. Najbezpieczniej jest używać `` (w Next.js zwykle przez ``), a jeśli UI ma wyglądać jak przycisk, to stylować link jak button, zamiast robić button udający link. Przyciski zostawiłbym do akcji (np. otwórz modal, dodaj do koszyka), a nawigację i CTA do podstron trzymał w anchorach. W praktyce taka zmiana często poprawia indeksację i linkowanie wewnętrzne, a przy okazji rozwiązuje sporo problemów z UX i dostępnością.

UXBartek 2026-02-12 10:57

W odpowiedzi do MarketingBartek

"Przerabiałem to u siebie i w kilku projektach klientów: dla użytkownika „klik” działa tak samo, ale dla robotów i dostępności różnica jest spora. `<a href>` daj"

Masz rację z tą różnicą „niewidoczną” dla użytkownika, ale bardzo widoczną dla robotów i dostępności: jeśli to ma prowadzić do innej podstrony, semantycznie powinien to być link z `href`. W praktyce crawler najpewniej i najszybciej odkrywa oraz mapuje serwis właśnie po atrybutach `href`, a nawigacja oparta wyłącznie o `onClick`/`router.push()` może osłabić wewnętrzne linkowanie (albo przynajmniej utrudnić jego pełne wykorzystanie). Do tego dochodzą realne minusy UX: brak standardowych zachowań typu otwarcie w nowej karcie, kopiowanie adresu czy przewidywalna obsługa klawiaturą i czytnikami ekranu. W Next.js najlepiej trzymać się komponentu linku (albo zwykłego `a`), a jeśli chcesz wygląd „przycisku”, to po prostu ostylować link jak button. `button` zostawiłbym do akcji, które nie są nawigacją (np. wysłanie formularza, otwarcie modala, filtrowanie na stronie). Przy ~300 podstronach i blogu to szczególnie ważne, bo sprawne odkrywanie i przepływ sygnałów wewnętrznych robią różnicę w dłuższym okresie. Jeśli gdzieś musisz zostać przy JS, to przynajmniej zadbaj, żeby w HTML i tak istniał prawdziwy, crawlowny `href` jako podstawowa ścieżka. Podsumowując: technicznie „działa”, ale dla SEO, dostępności i standardów webowych lepiej wrócić do linków.