Kategorie
Archiwum Newslettera

Jaki typ aplikacji React pod SEO? SPA, SG czy SSR?

Jak zadbać o SEO? Aplikacja napisana w Reakcie jest domyślnie skryptem JavaScript. Roboty indeksujące nie czytają JS, więc mamy problem. Jak sobie z tym poradzić? Co musisz wiedzieć o generowaniu aplikacji React?

Jak zadbać o SEO? Aplikacja napisana w Reakcie jest domyślnie skryptem JavaScript. Roboty indeksujące nie czytają JS, więc mamy problem. Jak sobie z tym poradzić? Co musisz wiedzieć o generowaniu aplikacji React?

Jak zadbać o SEO, czyli żeby moja strona była dostępna w wynikach wyszukiwania? Aplikacja napisana w Reakcie jest domyślnie skryptem JavaScript. Przeglądarka otrzyma praktycznie pusty dokument HTML, a sama treść zostanie obliczona w trakcie działania programu, w tzw. runtime. To nie jest dobre z punktu widzenia optymalizacji treści pod wyszukiwarki.

Oczywiście są sytuacje, kiedy SEO mnie nie obchodzi

SEO mnie nie obchodzi, gdy moja aplikacja jest dostępna tylko po zalogowaniu lub kiedy zwyczajnie nie mam tam nic istotnego do zaindeksowania. Może być tak, że wyniki wyszukiwania skupiają się na landing page, który jest już pod to zoptymalizowany.

Jak zrobić dobre SEO z Reaktem?

Natomiast są w Reakcie sposoby na serwowanie statycznej treści HTML właśnie pod SEO. Na początku wydawało mi się to nieco zagmatwane. Sprawa się wyjaśniła, gdy zrozumiałem jak renderowane są treści w aplikacjach front-end (nie tylko React). Dlatego chciałbym omówić typy aplikacji pod względem renderowania.

Single Page Application – SPA

SPA to właśnie aplikacja renderowana w trakcie działania – w runtime przeglądarki. Można w uproszczeniu założyć, że taka aplikacja jest jednym plikiem HTML (jedną stroną internetową). Nawet jeśli jest routing, to jest on obsługiwany z poziomu przeglądarki. Jedynym zadaniem serwera jest podanie zawsze tego samego pliku HTML z tym samym kodem JavaScript niezależnie od ścieżki. Nieważne czy wchodzisz na stronę główną /, czy jakąś podstronę np. /products, serwer zawsze zwraca to samo – aplikację SPA.
Niestety roboty indeksujące nie potrafią odczytywać kodu JavaScript. Moja treść jest zaszyta w skrypcie, więc strona nie zostanie poprawnie odczytana i zaindeksowana. Może to być kluczowy problem. Zawsze uzgadniam kwestie SEO, zanim zabiorę się za kodowanie.

Static Generation

W tym podejściu cała aplikacja jest generowana wcześniej, najczęściej już podczas budowania aplikacji. W podawanym pierwotnym dokumencie HTML znajduje się już wyrenderowana treść. Z punktu widzenia SEO wszystko jest OK. Przeglądarka dostaję już pełny kod HTML. Treść nie jest dynamiczna. Statyczny kod HTML jest generowany tylko raz w trakcie budowania strony.
Kolejnym plusem jest zwiększona wydajność – przeglądarka ma mniej pracy do wykonania, przez co strona szybciej się ładuje, co dodatkowo mogą wspomóc zaawansowane techniki ładowania zoptymalizowanych zasobów stosowane przy znanych frameworkach np. Gatsby lub Next.js.
Roboty indeksujące widzą treść, ale moja aplikacja jest już statyczna, raz wyrenderowana, trudniej ją aktualizować. Mimo tego, Next.js potrafi sobie z tym sprytnie poradzić generując statyczną stronę na żądanie. Strona jest generowana raz, przy pierwszym wejściu któregokolwiek użytkownika na stronę. Następny odwiedzający dostaje już wcześniej wygenerowany dokument HTML. Dodatkowo można ustawić czas odświeżania np. 10 minut. Wtedy mam w pewnym sensie dynamiczny zasób, ale generowany statycznie. Wymaga to niestety dodatkowej konfiguracji serwera (Vercel i Netlify mają to dostępne od ręki).

Server Side Rendering – SSR

Jak zjeść ciastko i mieć ciastko? 😎 Mogę podawać przeglądarce statyczne treści (gotowe dokumenty HTML) renderując je na serwerze, ale nie podczas budowania aplikacji, tylko w momencie każdego żądania, czyli wejścia użytkownika na stronę. Nie tracę nic na dynamiczności (jak w SPA), a przeglądarka rozumie treść, bo pierwszy render miał miejsce po stronie serwera i pełny dokument HTML jest już gotowy dla robota. Osiągniesz to używając frameworka Next.js.
Na zakończenie wspomnę, że SEO nie musi być jednym kryterium wyboru frameworka Next.js. Posiada on wiele ciekawych udogodnień. Z każdą wersją jest ich coraz więcej. Pewnie wspomnę jeszcze o nich. 90% projektów, które aktualnie rozwijam są właśnie pisane w Next.js. W większości z nich, to nie SEO było powodem naszego wyboru. Wybraliśmy Next.js, bo jest to framework z krwi i kości. Nie skupia się jedynie na warstwie front-end, a na całej aplikacji fullstack.