Răspuns scurt: în servicii locale, entity salience este utilă ca disciplină de claritate și consistență, nu ca scor de ranking. Arhitectura bună face evident ce entitate descrie fiecare pagină, ce informație deține și cum se leagă organizația de locații, servicii și persoane. Google documentează LocalBusiness și Organization structured data, dar nu publică un scor universal de salience pentru website-uri locale.

Precondiția 1: harta entităților

Începe cu o listă explicită:

  • organizația;
  • brandul;
  • locațiile;
  • serviciile;
  • persoanele/autori, unde sunt relevante;
  • service areas;
  • profilele externe critice.

Nu porni de la markup. Mai întâi trebuie să știi ce relații există în realitate.

Precondiția 2: ownerii informației

Programul unei locații poate fi deținut de operațiuni. Descrierea unui serviciu poate fi deținută editorial. Datele companiei pot fi deținute de administrativ.

Fără owneri, aceeași informație va diverge între pagini.

Arhitectura 1: organizație versus locație

Homepage și pagina About descriu organizația. Pagina locației descrie sediul sau service area concretă. Dacă există mai multe sedii, nu copia o biografie generică pe fiecare URL și nu amesteca adresele.

LocalBusiness markup trebuie să reflecte entitatea locală afișată.

Arhitectura 2: locație versus serviciu

O pagină de locație răspunde la „unde, când, cum contactez?”. O pagină de serviciu răspunde la „ce oferi, pentru cine, în ce condiții?”.

Leagă-le contextual. Nu transforma fiecare combinație oraș x serviciu într-un URL dacă nu există information gain.

Arhitectura 3: service area

Pentru business-urile mobile, aria de serviciu poate conta mai mult decât o adresă publică. Explică zonele reale și limitările, fără a crea pagini doorway pentru fiecare localitate.

Dacă anumite servicii nu sunt disponibile în toate zonele, această diferență este information gain legitim.

Arhitectura 4: autori și experți

Articolele și ghidurile pot avea autori reali, dar service pages nu au nevoie automat de byline individuală. Author identity și local entity sunt straturi diferite.

Nu crea profile artificiale pentru fiecare oraș.

Arhitectura 5: sursa canonicală pentru facts

Pentru program, telefon, adresă și condiții, alege sursa first-party care deține adevărul. Alte pagini pot afișa rezumatul sau linkul, dar nu ar trebui să inventeze versiuni independente.

Secvența de implementare

  1. construiești registry-ul entităților;
  2. clasifici paginile după entitatea principală;
  3. identifici duplicatele și conflictele;
  4. alegi ownerii pentru facts;
  5. repari first-party;
  6. aliniază structured data;
  7. actualizezi internal links;
  8. verifici profilele externe critice;
  9. rulezi QA;
  10. monitorizezi drift-ul.

Ordinea previne optimizarea markup-ului peste o arhitectură confuză.

Exemplu: firmă cu două sedii

Organizația are sediul A și sediul B. Ambele oferă serviciul X, dar doar sediul A oferă intervenții sâmbăta. Pagina serviciului explică ce este serviciul și cine este eligibil. Paginile locațiilor explică programul și disponibilitatea locală.

Nu ai nevoie de două articole identice despre serviciul X. Ai nevoie de un owner pentru serviciu și diferențe locale explicite.

Exemplu: service-area business

O echipă de instalatori nu primește publicul la sediul administrativ. Pagina principală explică serviciile și zonele acoperite. Paginile locale sunt justificate numai dacă au informații distincte despre disponibilitate, logistică sau condiții.

Adresa administrativă nu trebuie forțată ca punct de lucru public.

Internal linking

Leagă locația către serviciile disponibile și serviciul către locațiile relevante. Anchor text trebuie să descrie destinația, nu să repete mecanic keyword-ul.

Google recomandă linkuri crawlable și anchor text contextual.

Structured data

Folosește Organization pentru organizație și tipul LocalBusiness potrivit pentru locația reală, unde ghidajul se aplică. Markup-ul trebuie să reflecte conținutul vizibil.

Nu completa proprietăți doar pentru că există în vocabular.

Acceptance criteria

Arhitectura trece gate-ul când:

  1. fiecare pagină are o entitate principală clară;
  2. locațiile active au registry și owner;
  3. serviciile au un owner canonical;
  4. combinațiile localitate-serviciu au information gain sau nu există ca pagini separate;
  5. first-party conflicts materiale sunt zero sau au task activ;
  6. structured data reflectă pagina;
  7. internal links continuă task-ul utilizatorului;
  8. profilele externe critice sunt mapate;
  9. nu există doorway-like local duplication;
  10. monitorizarea are denominatori și criterii de oprire.

Rollback și limitări

Dacă o pagină locală nouă nu justifică existența, consolideaz-o. Dacă structured data introduce informație neverificată, revino la o versiune mai simplă. Dacă service-area mapping devine imposibil de menținut manual, mută datele într-un registry operațional.

Nu păstra complexitatea doar pentru că a fost implementată.

Cum măsori după implementare

First-party conflict rate, owner coverage, duplicate-intent count, external critical-profile consistency și time-to-resolution sunt metrici directe. Search și AI mentions rămân outcomes separate.

Cum tratezi business-urile cu modele hibride

Unele companii au sedii fizice, echipe mobile și programări online. Nu încerca să le reduci la o singură relație simplă. Registry-ul poate păstra separat physical location, service area și remote service, iar paginile trebuie să explice ce opțiune este disponibilă pentru fiecare serviciu.

Acest lucru previne situația în care un utilizator vede o adresă și presupune că poate veni fără programare, deși operațiunea reală este doar pe teren.

Trigger-e de revizie

Reia auditul după relocare, program sezonier, lansarea unui serviciu, schimbarea telefonului, rebrand sau restructurarea paginilor locale. O arhitectură bună nu este „set and forget”; trebuie legată de evenimentele care schimbă adevărul public.

Claim ledger

  • FACT/EVIDENCE: Google documentează LocalBusiness și Organization structured data.
  • FACT/EVIDENCE: Google recomandă linkuri crawlable și conținut util pentru utilizatori.
  • PRACTITIONER GUIDANCE: entity architecture trebuie să separe organizația, locația și serviciul.
  • NOT PROVEN: un entity salience score universal sau un efect garantat asupra ranking-ului/citărilor AI.

Concluzie

Entity salience locală înseamnă că utilizatorul și sistemele automate pot înțelege fără contradicții cine e organizația, unde operează și ce oferă. Când această arhitectură este clară, markup-ul și monitorizarea devin mai simple. Când nu este, niciun scor extern nu repară confuzia de bază.

Surse revizuite

Articole conexe