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 <button> z onClick, które odpala router.push() zamiast klasycznego <a href>. Z perspektywy użytkownika działa to jak zwykły link, ale w HTML nie ma href, tylko zdarzenie w JavaScript. W Search Console mam wrażenie, że nowe podstrony pojawiają się wolniej niż wcześniej, a audyt techniczny wyłapał sporo „orphan pages”, mimo że są dostępne z nawigacji. Budżet na poprawki w tym etapie to ok. 12 tys. zł i muszę dobrze ustalić priorytety na najbliższy sprint. Czy Google traktuje takie „linki” oparte o przyciski i JS jak normalne linki wewnętrzne do crawlowania i przekazywania sygnałów, czy może je częściowo pomijać? Jeśli to ma znaczenie, większość ruchu mamy z Polski i celujemy głównie w frazy usługowe, nie tylko w content z bloga.

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 `<button>` z `router.push()` są renderowane po stronie serwera (w „View source”) jako normalne `<a href>` przez `next/link`, czy dopiero klientowo po JS? I czy w tych miejscach masz też prawidłowe elementy semantyczne (np. `nav`, nagłówki) oraz fallback bez JS, czy zakładasz, że robot zawsze wykona skrypty?

MarketingEwa 2026-02-11 14:49

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 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 `<button>` bez `href`, to traktuję to jako realny problem: część botów i narzędzi audytowych nie widzi wtedy tych przejść jak klasycznych linków, a wewnętrzne linkowanie robi się „niewidzialne” bez uruchomienia JS. W Next.js najlepiej, żeby w HTML finalnie lądowało normalne `<a href>` (np. przez `Link`), bo wtedy masz i crawl, i sensowną dostępność, i działanie przy problemach z JS. Same role/aria na buttonie pomagają dostępności, ale nie zastępują semantyki linku i nie rozwiązują kwestii braku `href`. Miałem przypadek na większym serwisie, gdzie nawigacja i kafelki były zrobione na `onClick`, działało „dla ludzi”, ale po zmianie na anchor/linki Google szybciej łapał głębsze podstrony i zniknęły uwagi z audytu o nawigacji niebędącej linkami. Do CTA i elementów nawigacyjnych konsekwentnie używam `<a>` (nawet jeśli wyglądają jak przycisk), a `<button>` zostawiam do akcji typu wysłanie formularza, otwarcie modala itp. Jeśli koniecznie zostaje `router.push()`, to przynajmniej dublowałbym to prawdziwym `href` w markupie, bo inaczej ryzykujesz i SEO, i UX przy słabszych warunkach. W skrócie: jeśli po SSR nie masz `href` i bez JS to nie działa, to warto to poprawić, zwłaszcza przy menu, kategoriach i landingach.

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) `<a href>` 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 `<a>`/`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 `<button>` potrafią robić bałagan pod SEO i dostępność, bo roboty i narzędzia nie zawsze traktują to jak prawdziwą nawigację. Z perspektywy indeksowania najbezpieczniej jest mieć normalne `<a href>` (w Next po prostu `Link`), a JS niech będzie tylko dodatkiem, nie jedynym sposobem przejścia. U mnie po podmianie kluczowych miejsc (menu, listy, kafelki, CTA) na linki poprawiła się spójność crawl’u i zniknęły dziwne przypadki, gdzie podstrony „odkrywały się” wolniej. `<button>` zostawiłbym do akcji w obrębie strony, a do przejść między URL-ami zawsze link.

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 href>`, a `button` z `onClick` bywa pomijany lub gorzej rozumiany (zwłaszcza bez SSR). Jeśli to ma prowadzić na inną podstronę, lepiej użyć `<a>`/`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 `<a href>` (łatwiejsze crawl/link equity, prefetch, kanoniczna nawigacja), a `<button>` z `onClick` potrafi być pomijany lub gorzej interpretowany. U nas po podmianie krytycznych miejsc (menu/CTA/kafelki) na `<a href>` w Next.js indeksacja i wewnętrzne linkowanie zrobiły się bardziej stabilne, bez zmian “na oko” dla użytkownika.

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. `<a href>` 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ć `<a href>` (w Next.js zwykle przez `<Link href>`), 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.