Server tərəfində və müştəri tərəfində render: SEO üçün hansı daha yaxşıdır?

Hər veb-sayt öz arxitekturasının hansısa nöqtəsində HTML-in əslində harada yaradılacağına qərar verməlidir. Server tərəfində render (SSR) zamanı server tam HTML səhifəsini yığır və onu artıq kontentlə doldurulmuş şəkildə brauzerə göndərir. Müştəri tərəfində render (CSR) zamanı isə server demək olar ki, boş HTML «qabığı» və JavaScript paketi göndərir, real səhifəni isə brauzer JavaScript yüklənib icra olunduqdan sonra qurur. Sürətli bağlantısı və müasir brauzeri olan istifadəçi üçün hər iki yanaşma vizual olaraq eyni nəticə verə bilər. Onlar ondan əvvəl baş verənlərdə fərqlənir — SEO problemləri də adətən məhz bu boşluqda yaranır.

Google JavaScript-dən çox istifadə edən səhifə ilə əslində nə edir

Google JavaScript-i render edə bilir. Bu, artıq neçə illərdir belədir. İnsanları çaşdıran nüans isə budur ki, Google-un render prosesi ilkin skanlamadan ayrı, ikinci mərhələdə baş verir və Google tərəfində daha çox hesablama resursu tələb edir — ona görə də bu proses nə dərhal baş verir, nə də Google-un səbri sonsuzdur. Kontentini göstərmək üçün tamamilə müştəri tərəfindəki JavaScript-dən asılı olan səhifə Google-dan server tərəfində render olunmuş səhifənin dərhal təqdim etdiyini görmək üçün əlavə iş görməyi tələb edir. Kiçik saytda bu, nadir hallarda fəlakətli olur. On minlərlə səhifəsi olan böyük saytda isə yavaş və ya etibarsız render mərhələsi səhifələrin gec indekslənməsi, natamam kontentlə indekslənməsi və ya ümumiyyətlə indekslənməməsi ilə nəticələnə bilər.

Digər axtarış robotları və platformalar — sosial şəbəkələrdə link önizləmələri, bəzi Sİ robotları, müxtəlif SEO alətləri — çox vaxt JavaScript-i render etməkdə Google-dan xeyli zəifdir. Yalnız CSR-ə əsaslanan səhifə onlara tamamilə boş görünə bilər; bu da link önizləmələrinə, strukturlaşdırılmış məlumatların çıxarılmasına və tam brauzeri işə salmaq əvəzinə real nişanlamanı (markup) oxumaqdan asılı olan hər şeyə təsir edir.

CSR harada tamamilə yerindədir

Hər səhifənin indekslənməsi, tətbiqin hər hissəsinin axtarış robotları tərəfindən skanlanması lazım deyil. Giriş tələb edən bölmələr, idarəetmə paneli, sifarişin rəsmiləşdirilməsi prosesi — bunların heç biri axtarış sistemləri üçün kontent deyil və CSR orada yaxşı işləyir, çünki auditoriya axtarış robotu deyil, JavaScript-i aktiv olan real brauzerdir. Məhsulunuz əsasən bir neçə ictimai marketinq səhifəsi olan, giriş tələb edən tətbiqdirsə, praktik cavab çox vaxt hibrid yanaşmadır: axtarışda mövqe tutmalı olan səhifələri serverdə render edin, giriş tələb edən tətbiqi isə müştəri tərəfində render olunan tək səhifəli tətbiq (SPA) kimi saxlayın — axı heç kim Google-da sizin girişdən sonrakı idarəetmə panelinizi axtarmır.

SSR öz mürəkkəbliyini harada doğruldur

Bütün vəzifəsi axtarışda tapılmaq olan istənilən səhifə — məhsul səhifələri, bloq yazıları, kateqoriya və siyahı səhifələri, məkan səhifələri, sənədləşmə — SSR-dən və ya statik generasiyadan (bu, əslində hər sorğuda deyil, yığım (build) zamanı icra olunan SSR-dir) fayda görür. Kontent ilkin HTML cavabında mövcuddur, ona görə də ikinci render mərhələsinin uğurla keçməsindən asılılıq yoxdur. Bundan əlavə, belə səhifə real ziyarətçi üçün də adətən daha tez yüklənir, çünki brauzer ekranda nəsə görünməzdən əvvəl JavaScript paketinin yüklənməsini, təhlil olunmasını və icrasını gözləmir — bu isə Core Web Vitals üçün və nəticə etibarilə konversiya üçün vacibdir.

Kompromis realdır: SSR server tərəfinə mürəkkəblik əlavə edir və freymvorkdan asılı olaraq keşləmə, hidratasiya və server ilə müştəri arasında sinxronlaşdırılmalı olan vəziyyət (state) ilə işləmə qaydasını dəyişir. Müasir freymvorklar bunu əvvəlkindən xeyli asanlaşdırıb: nadir dəyişən kontent üçün statik generasiya, dəyişən kontent üçün isə inkremental regenerasiya kimi yanaşmalar sayəsində bütöv sayt üçün «tam statik» və «tam dinamik» arasında seçim etmək məcburiyyətində qalmırsınız.

Praktik yoxlama siyahısı

• Səhifə axtarışda mövqe tutmalı və ya link önizləməsi kimi paylaşılanda düzgün görünməlidirsə, onu serverdə və ya yığım zamanı render edin.
• Səhifə autentifikasiya arxasındadırsa və heç vaxt axtarış robotları tərəfindən skanlanmayacaq, ictimai paylaşılmayacaqsa, müştəri tərəfində render ağlabatan və daha sadə standart seçimdir.
• Yalnız JavaScript icra olunduqdan sonra brauzerin developer tools inspektorunda gördüyünüzü deyil, xam, render olunmamış HTML cavabını göstərən alətlə yoxlayın — çünki axtarış robotunun ilk mərhələdə gördüyünə daha yaxın olan məhz budur.
• «Google JavaScript-i render edə bilir» ifadəsini «bunun heç bir əhəmiyyəti yoxdur» kimi başa düşməyin. Böyük miqyasda, yavaş serverdə və xəbərlər və ya anbar qalıqları kimi vaxta həssas hər şeydə bunun əhəmiyyəti daha da artır.

Bunu əvvəldən düzgün qurmaq — saytın hansı hissələrinin serverdə render olunmalı, hansılarının isə müştəri tərəfində qala biləcəyinə qərar vermək — Burncode-da hər veb-proqramlaşdırma layihəsində verdiyimiz ilk arxitektura qərarlarından biridir, çünki sayt artıq hazırlanıb axtarışdakı görünürlüyünü itirməyə başlayandan sonra bunu sonradan dəyişmək əvvəlcədən planlaşdırmaqdan qat-qat böyük işdir.