System wyświetlania postów na stronie www

Question

Witam.

Postanowiłem napisać sobie coś w rodzaju bloga. Wyglądało by to tak, że osoba wchodzi na stronę www gdzie jest lista postów, po kliknięciu w post przenosi ją na stronę gdzie może przeczytać go całego.

Teraz rodzi się pewien problem. Tworzenie podstrony pod każdy post byłoby głupie ze względu na to, że tych postów po roku może być tysiące ( zamierzam go prowadzić w dużej grupie osób ). Rozwiązaniem może być stworzenie jednej strony, na której wczytywałby się post z bazy na podstawie danych zawartych w linku ( GET ). Wydaje się to dobre pod kontem redundancji kodu, lecz co wtedy z SEO? Nie pogorszy to wyniku wyszukiwań?

Pozdrawiam!

Answer 1

Tak, wczytanie z bazy to jak najbardziej słuszny pomysł.

Jeśli chodzi o linki to bez problemu można zrobić ich przepisywanie. Czyli np. post.php?id=5 zamienić na /post/5. Co więcej, w bazie można też trzymać opisową część linka - np. "to-jest-tytul-posta", a następnie we wspomnianym wcześniej przepisywaniu użyć tego zamiast liczby. Pojawia się wtedy kwestia unikalności linka, albo musi być unikalny albo zawierać jeszcze dodatkowo np. id, aby było wiadomo o którego posta na pewno chodzi. Tym sposobem możesz uzyskać normalny adres w rodzaju /post/to-jest-tytul-posta.

Jeszcze innym podejściem, które jest teraz spotykane w większości aplikacji, jest robienie routingu po stronie kodu, a na serwerze skierowanie każdego wywołania na aplikację (każdego z wyjątkiem faktycznie istniejących plików). Dzięki temu cała decyzja o tym co zrobić zapada po stronie aplikacji, tam jest zdefiniowane dla jakiego adresu co ma zrobić. Serwer tylko zawsze kieruje do aplikacji, jakiegoś jednego pliku wejściowego. Takie rozwiązanie jest też używane we frameworkach, np. w Symfony czy Laravelu.

Comments

Dziękuję za odpowiedź! Chyba nie do końca zrozumiał Pan mój wątek, głównie chodzi mi o SEO.

---

No zapytałeś o ewentualny problem z SEO, gdy strona będzie ładowana z bazy. Założyłem (może mylnie), że chodzi Ci głównie o link, który domyślnie przy użyciu GET będzie wyglądał brzydko (np. właśnie post.php?id=5), dlatego napisałem że w linku można też umieścić jakiś tekst, który będzie opisywał co jest na danej stronie i jeszcze ładnie to przepisać, czyli powinno to być dobre dla SEO. Jeśli nie chodziło tylko o link to co jeszcze? Treść całej strony generujesz i dostosowujesz na podstawie danych posta z bazy, sam to napisałeś, więc myślałem że wiesz.

PS niepotrzebnie "pan" :)

---

Hmm, najwyraźniej nie do końca rozumiem jak działa SEO.

Dajmy na to: mam podstronę gdzie jest artykuł. Podstrona jest zrobiona na ten zły sposób, czyli wygenerowana "ręcznie" wraz z zawartością artykułu. Robot w przeglądarce normalnie będzie mógł odczytać, że taka strona istnieje i ewentualnie wyświetlić ją na liście wyszukiwań użytkownikowi.

W przypadku gdzie artykuł jest wczytywany z bazy to strona jest generowana przez użytkownika. Jak robot google uzna, że taka strona istnieje, skoro istnieje tylko jej część statyczna ( nagłówek, stopka, nawigacja itd ) a sama zawartość artykułu dopiero zostanie wczytana gdy użytkownik wejdzie na stronę?

 

Może wcześniej nie doprecyzowałem, ale artykuły na stronie będą o różnej tematyce, przez co chciałbym aby np. gdy użytkownik wpisał frazę związaną z Java to przeniosło go do artykułu odnośnie Javy, a gdy fraza byłaby związana z samorozwojem to również na odpowiedni artykuł.

---

Dla google ważne jest aby w pierwszym response poszedł html z tekstem artykułu. Nie ma znaczenia w jaki sposób wygenerujesz html, liczy się tylko to, co serwer wypluje jako html do sparsowania przez przegladarke.

Obecnie coraz lepiej google radzi sobie tez z js client side, ale jednak co ssr tk ssr :)

---

Bardziej wydaje mi się, że nie do końca rozumiesz jak działa PHP (albo chodzi o coś bardziej frontendowego i wybrałeś złą kategorię). PHP jest językiem backendowym i klient nie dowie się i nie ma wpływu na to, co zrobi PHP (za wyjątkiem rzeczy zaprogramowanych oczywiście). Bez znaczenia jest czy zapytanie wyśle przeglądarka użytkownika, Google, jakiś napisany skrypt czy jeszcze inny klient - PHP po prostu wykona to co ma zaprogramowane i odpowie (chyba że sam stworzysz jakieś warunki). Odpowiedzieć może kodem HTML albo czymkolwiek innym.

Wystarczy więc, że w PHP zrobisz generowanie takiej strony (kodu HTML) z danym postem - dostosujesz ją tak, jak sobie zamarzysz. Możesz dla każdego artykułu ustawiać inny title, mety, treści, a nawet i w ogóle generować całkowicie inny kod HTML na każdą podstronę. Google czy przeglądarka po prostu dostaną odpowiedź i nie mają pojęcia o tym czy na backendzie to jest fizyczny plik HTML czy może tam jest PHP, który przygotował kod HTML i odesłał. Po prostu nadeszła odpowiedź z serwera, a co ją wysłało to generalnie nie bardzo interesuje klienta, który wysłał żądanie.

Inną sytuacją są rzeczy doczytywane w JavaScript na frontendzie. Wtedy faktycznie, jeśli zrobisz coś takiego, że ktoś będzie załóżmy klikał przycisk na stronie, w tym momencie zostanie wysłane zapytanie do serwera w tle (Ajax) i JS wstawi dynamicznie odpowiedź na stronę, to Google sobie z tym nie poradzi - prawdopodobnie nie wykona kodu JS i nie zobaczy tej treści, którą wstawia JS. Na to też są oczywiście rozwiązania, bo można robić i całe aplikacje SPA np. w Vue czy React i po zastosowaniu SSR też można wyszukiwarkom zwrócić jakąś odpowiedź wygenerowaną przez serwer, ale wydaje mi się, że nie pytałeś aż o takie rzeczy.

---

Bardzo dziękuję za szczegółowy opis, wszystko zrozumiałem.