TSM - SEO – time is money

Dacă site-ul tău ar fi un muzeu, iar vizitatorii ar avea la dispoziție doar o oră pentru a-l vizita, ce le-ai arăta?

Ce este SEO?

SEO (Search Engine Optimization) este un set de practici și strategii aplicate unui site web cu scopul de a îi crește relevanța și vizibilitatea.

Pentru a face paginile unui site web accesibile pentru cât mai mulți utilizatori, niște programe numite web crawlers (cunoscute și sub numele de spiders sau bots) navighează în mod sistematic pe World Wide Web pentru a colecta și indexa informațiile de pe site-uri. Rezultatele relevante ale crawlingului sunt afișate ulterior utilizatorilor prin intermediul motoarelor de căutare precum Google, Bing sau Yahoo.

Un crawler web, cum ar fi Googlebot (crawlerul principal al Google), nu alocă un timp fix pentru un site, predictibil, cunoscut și sub formă de crawling budget, însă alocă diverse cuante de timp care trebuie maximizate de către strategia SEO folosită. Dacă în cazul unor site-uri cu pagini statice sau modificate rar, cum ar fi blogurile, optimizarea bugetului de crawling nu este prioritară, în cazul site-urilor cu conținut dinamic generat în volum mare (site-uri de știri, marketplace-uri, platforme de pariuri etc.), orice detaliu face diferența privind poziția site-ului în rezultatele afișate de către motorul de căutare.

Pentru a facilita descoperirea de către boți a linkurilor nou apărute pe un site în continuă schimbare, pe lângă calitatea intrinsecă a conținutului paginilor web, site-ul expune și sitemapuri de tip XML și HTML. Folosindu-se de acestea, boții află despre existența linkurilor, frecvența actualizării lor, priorități, echivalențe în alte limbi, structura generală a site-ului, fără a mai fi nevoit să facă un crawling propriu-zis și o parsare a fiecărei pagini. De reținut este faptul că aceste hărți cu linkuri nu înlocuiesc crawlingul, ci joacă doar un rol complementar.

Use case: analiză platformă de pariuri sportive

Un site de pariuri sportive are următoarele particularități:

• conținut dinamic:

  • evenimentele sportive (meciurile) au o durata mică, de cel mult câteva ore, iar cotele lor se modifică în permanență, în special în cazul evenimentelor aflate în desfășurare

• structură complexă a site-ului:

  • pagini de multe tipuri:

  • sporturi (fotbal, tenis etc.),

    • competiții (Premier League, Turul Franței etc.),

    • evenimente,

    • marketuri,

    • promoții/bonusuri,

    • rezultate,

    • blog.

  • volume:

    • de pagini active, care returnează status code 200, este uzual de ordinul a zeci de mii.

Pentru aceste caracteristici specifice, se pretează abordări SEO specifice:

• XML sitemaps generate frecvent

  • pagini prioritizate prin reguli și CMS-uri (Content Management Systems)
• îmbunătățirea timpilor de răspuns pentru pagini.

Sitemaps

În mod uzual, sitemapurile conțin toate URL-urile de pe site, atât în format XML (referite încă din fișierul standard robots.txt), cât și în format HTML. Dacă primele sunt mult mai utile pentru boți, cele din urmă sunt orientate spre utilizatorul uman al site-ului, însă oferă și indicii boților despre structura arborescentă de pe site, despre relația dintre pagini, fiind complementare sitemapurilor XML.

Însă ce facem când dispunem de un crawling budget limitat și avem peste 10,000 de

URL-uri pe site aflate într-o continuă schimbare (se termină meciuri, încep altele)?

1. Împrospătăm sitemapurile frecvent, în funcție de tipul paginii.

   • Propunem următoarele frecvențe de refresh.

     1. Meciurile trebuie incluse în sitemap imediat ce apar pe site și scoase cât mai repede după ce acestea s-au încheiat. Ex: 10 minute.

     2. O competiție sportivă se actualizează mai rar, întinzându-se uzual pe mai multe etape. Ex: 1 oră.

     3. Un sport există aproape întotdeauna. Ex: 24 ore

     4. Link-urile unor pagini precum homepage, landing page sunt statice. Ex: 7 zile.

   • Pentru fiecare frecvență de generare, alegem cea mai apropiată valoare permisă în XML sitemap conform XSD-ului oficial:

     1. 10 minute => always,

     2. 1 oră => hourly,

     3. 24 ore => daily,

     4. 7 zile => weekly.

2. Alocăm priorități evenimentelor în funcție de:

   • Perioada anului.

     1. Exemplu: În luna mai prioritizăm finala UEFA Champions League.

   • Domeniu și limbă.

     1. Exemplu: paginile de pe https://www.betfair.ro/ , limba română, sunt accesate de utilizatori români care sunt mai tentați să parieze pe sportivii sau echipele românești decât pe ligi superioare calitativ, dar care nu sunt de top, precum cele din Cehia, Belgia sau Turcia.

3. Înștiințăm boții prin mecanisme de tip ping după o regenerare.

   • Exemplu pentru Googlebot: http://www.google.com/ping?sitemap=https://www.betfair.ro/sitemaps/sportsbook-events-ro.xml

4. Excludem linkurile care nu sunt de interes pentru a maximiza șansa celorlalte de a fi vizitate în cuanta de timp alocată.

   • Competiții mai puțin importante:

     • Exemplu: Regionalliga (liga a 4-a de fotbal din Germania) cu toate meciurile și marketurile aferente.

   • Sporturi nepopulare în anumite țări:

     1. Exemplu: horse racing sau cricket în România.

   • Sporturi sezoniere:

     1. Exemplu: sporturi de iarnă în timpul verii.

Exemplu:

<urlset 
 xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9”>
<url>

<loc>
 https://www.betfair.ro/sport/football/anglia-premier-league/newcastle-v-liverpool/34630163 
</loc>

<lastmod>2025-08-19T17:36+00:00</lastmod>
<changefreq>always</changefreq>
<priority>0.7</priority>
</url>
...
</urlset>

Din același CMS, la pachet cu excluderea din XML sitemap pentru un URL, putem adăuga și o meta informație în cadrul paginilor HTML:

<meta name="robots" content="noindex, nofollow">

având următoarele scopuri:

• noindex: motoarele de căutare nu vor include pagina în rezultatele căutării.

• nofollow: motoarele de căutare nu vor urma linkurile de pe pagină (deci nu vor transmite "autoritate" SEO către acele linkuri).

în cazul în care paginile sunt găsite prin mecanismul de crawling, nu pornind de la XML sitemaps.

Response time

Fiindcă ne dorim ca un bot de crawling să parcurgă cât mai multe pagini în timpul dat, o țintă importantă este să reducem timpul de răspuns al paginilor web.

Strategiile clasice de tip minificare HTML ajută în primul rând utilizatorul prin reducerea timpului de descărcare și randare, botul beneficiind de aceleași avantaje ca efect secundar. Însă în continuare ne concentrăm pe strategii destinate botului, fără impact asupra utilizatorului uman.

Un prim lucru pe care trebuie să îl evităm este fenomenul numit cloaking, o practică prin care un site web afișează conținut diferit pentru boți față de ceea ce vede utilizatorul real cu scopul de a manipula indexarea. O asemenea abordare poate duce la penalizări SEO, scoaterea paginilor din index sau la scăderi drastice în ranking pentru un website. Pentru a evita cloakingul este important să returnăm același conținut și ideal același status code, dar avem flexibilitate în ceea ce privește prezentarea (layout, interactivitate) și eventuala pre-randare.

Dacă avem pagini statice, putem să le cacheuim încă de la nivel de CDN, gestionând corect politica de expirare sau invalidare a cache-ului când se schimbă conținutul.

Alternativa ar fi doar să le pre generăm (SSG = Static Site Generation) și să le servim direct de pe server.

În cazul paginilor cu conținut dinamic se întâlnesc două mari abordări:

Server-side rendering (SSR):

• HTML-ul final și complet este generat la nivel de server pentru fiecare request, apoi este trimis direct către browser care afișează conținutul imediat, fără să aștepte JavaScript pentru a construi pagina.

• avantaj - performanță bună de la primul request.

• dezavantaj - consum mai mare de resurse pe server.

• exemple: Java + JSP, Spring Boot + Thymeleaf

Client-side rendering (CSR) :

• serverul livrează către browser o pagină minimală (de obicei un HTML foarte simplu + cod JavaScript), browserul execută JavaScript-ul și construiește HTML-ul final.

• avantaj - reducerea loadului de pe server, deoarece serverul trimite doar resurse statice, iar browserul se ocupă de toată munca legată de UI

• dezavantaje

  • prima încărcare de pagină este mai lentă.

  • SEO mai dificil, întrucât boții nu pot mereu sau nu alocă timp să execute codul JavaScript, iar timpul până la afișarea primului conținut (FCP = First Contentful Paint) este prea mare, această metrică fiind importantă din punct de vedere SEO
• exemple: pagini construite cu React, Angular, Vue.js

Pentru a gestiona paginile de tip CSR, se introduce un layer de tip proxy care transformă CSR-ul în SSR de fiecare dată când requestul provine de la un bot de crawling identificabil pe baza valorii HTTP header-ului User-Agent.

Acesta rezolvă problema funcțională, însă deoarece rezultatul pre-randării este un HTML static, se pretează și pentru a ține un cache cu aceste pagini pre-randate pentru a servi conținutul mai rapid în cazul următoarelor request-uri.

Cum optimizăm timpii de răspuns pentru paginile cached?

• Folosim un in-memory cache utilizând tehnologii precum Couchbase, Redis, Memcached, Ehcache sau Hazelcast.

• Începând cu cea de-a doua accesare, timpii de răspuns vor fi diminuați de zeci de ori (empiric, pentru cazul analizat, de ~30x), ceea ce înseamnă că de la un punct încolo, într-un timp dat, vom putea servi de zeci de ori mai multe pagini către boți.

Cum ne protejăm de umplerea memoriei cu pagini cached?

• Folosind un eviction policy implicit în funcție de tipul paginii sau status code-ul acesteia.

  • Exemplu de structurare ierarhică - unde varianta cea mai specifică are prioritate în fața variantei generale - exemplu: xxx - 7 zile, 2xx - 3 zile, 20x - 2 zile, 200 - 1 zi.

• Folosind mecanisme explicite de eviction atunci când anumite pagini expiră - soluție pretabilă mai ales în cazul paginilor perisabile (meciuri, marketuri etc.)

  • În acest caz, fiindcă boții încă știu de existența URL-urilor, cel mai eficient nu este să scoatem pagina din cache, ci să îi schimbăm starea de fiecare dată când consumăm un mesaj care ne înștiințează că un anumit eveniment s-a finalizat. Evictionul va fi parțial, însă suficient de bun având în vedere că status code-ul ocupă foarte puțini biți în comparație cu pagina propriu-zisă.

    • Status-Code: 200 OK => 410 Gone,

    • eliminăm HTML-ul stocat din cache.
• Normalizând fiecare URL. Pentru a evita hackurile utilizatorilor care pot adăuga/scoate un trailing slash, encoda anumite caractere, adăuga custom query params, normalizăm URL-urile pe server. Astfel ne asigurăm că fiecare pagină HTML este stocată o singură dată.

Cum eficientizăm stocarea?

Arhivăm. Fiindcă fiecare site poate avea zeci de mii de pagini, iar acesta poate să existe în diferite forme (pe mai multe domenii, în mai multe limbi), pentru 500,000 de pagini cu o medie de 500 kB per pagină, am avea o nevoie de 250 GB spațiu de stocare, ceea ce ar fi acceptabil pentru storage pe disk, dar foarte scump pentru a stoca în RAM. Empiric, prin compresie putem reduce aceste valori de ~25x, de la 250 GB până 10 GB de RAM.

Concluzii

Dacă vrei să ascunzi ceva, nu îl pune într-un seif, ci pe pagina a doua din Google.

Și fiindcă puțini își amintesc cine a ieșit pe locul 2 într-o cursă, împletește strategiile de business cu finețea tehnică dacă vrei un site remarcabil.