Răspuns scurt: pentru servicii locale, internal linking trebuie să conecteze service pages, location pages, service-area pages, explainers și contact/booking flows fără să creeze rețele artificiale de orașe. Google recomandă linkuri HTML crawlable și anchor text contextual. Nu publică un topical-authority score, iar mai multe linkuri nu compensează pagini locale fără information gain.
Precondiția 1: page-role policy
Definește rolurile înainte de links. Service page deține serviciul. Location page deține informația despre sediu. Service-area page există doar dacă are context și valoare distinctă. Explainerul răspunde unei probleme educaționale. Contact sau booking este next step operațional.
Precondiția 2: location model
Separă locații fizice de service areas. Nu inventa adrese și nu crea pages pentru localități doar ca să obții links geografice.
Precondiția 3: lifecycle
Păstrează active, relocated, temporarily_closed, closed, service_added și service_removed. Links trebuie actualizate când starea se schimbă.
Arhitectura 1: service hub
Pagina serviciului poate lega locațiile unde serviciul este disponibil și explainers care ajută decizia. Nu trebuie să enumere mecanic fiecare oraș din piață.
Arhitectura 2: location page
Pagina locației leagă serviciile reale oferite acolo, programarea și informația locală utilă. Nu linka servicii indisponibile doar pentru coverage.
Arhitectura 3: service-area page
Această pagină are sens dacă procesul, aria, logistica sau condițiile locale diferă suficient. Dacă textul este clonă, consolidarea este mai bună decât un graph mai dens.
Arhitectura 4: explainers
Articolele educaționale trimit către service owner doar când utilizatorul poate trece natural de la informație la acțiune.
Arhitectura 5: FAQs și guides
Nu genera FAQs doar pentru internal linking. Fiecare pagină trebuie să răspundă unei nevoi distincte și să aibă owner.
Arhitectura 6: booking/contact
Links către contact trebuie să păstreze locația și serviciul corecte. Un button cu event handler nu trebuie să fie singura cale către URL-ul de programare.
Arhitectura 7: breadcrumbs
Breadcrumbs reflectă ierarhia reală și ajută orientarea. Nu forța o taxonomie geografică dacă modelul de business este service area.
Arhitectura 8: related content
Automated modules trebuie să includă service, location, lifecycle și language context. Similaritatea lexicală singură poate recomanda pagini greșite.
Arhitectura 9: relocated locations
După mutare, actualizează upstream links, contact flows și relevant redirects. Un redirect valid nu înseamnă că graph-ul este curat.
Arhitectura 10: multi-language
Links trebuie să păstreze limba și piața. Nu trimite utilizatorul pe alt locale doar pentru că pagina are același subiect.
Exemplu 1: service + două locații
Pagina serviciului trimite la cele două sedii unde este disponibil. Fiecare location page trimite înapoi la service page și spre booking-ul specific. Un articol despre proces trimite la service page, nu la toate locațiile.
Exemplu 2: service-area business
O firmă fără sedii publice folosește o pagină centrală de serviciu și doar câteva pages de arie unde există informație distinctă despre logistică, acoperire sau timp. Nu construiește zeci de clone municipale.
Exemplu 3: locație închisă
Location page poate redirecționa spre sediul succesor doar dacă relația este clară. Upstream links trebuie schimbate către destinația finală, nu lăsate prin redirect la nesfârșit.
Audit decision tree
- Source page are rol clar?
- Target-ul este activ?
- Serviciul există în acea locație?
- Linkul continuă task-ul?
- Target-ul este crawlable și canonical?
- Anchor-ul descrie destinația?
- Market și language sunt corecte?
- Service-area page are information gain?
- Redirectul ascunde debt?
- Automated module respectă lifecycle?
- Booking path păstrează contextul?
- Finding-ul poate fi închis verificabil?
Acceptance criteria
Arhitectura trece gate-ul când:
- page roles sunt definite;
- location model este adevărat;
- serviciile sunt legate doar unde sunt disponibile;
- links importante sunt crawlable;
- anchors sunt descriptive;
- lifecycle changes declanșează recheck;
- service-area clones sunt evitate;
- modules au guardrails;
- locale/market routing este corect;
- booking paths funcționează.
Rollback
Păstrează graph snapshot înainte de schimbări mari. Dacă o regulă automată produce wrong-location sau wrong-service links, revino la manifestul anterior și dezactivează regula înainte de alt rollout.
Cum măsori
Orphan rate, wrong-target rate, wrong-location rate, redirect-link rate, module relevance și path completion sunt metrici utile.
Traffic și AI citations sunt outcomes externe.
Criteriu de maturitate
Sistemul este matur când relocation și service changes actualizează graph-ul predictibil, clonele locale nu reapar și P0/P1 sunt rare după release-uri.
Cum tratezi schimbarea ariei de servicii
Dacă un serviciu devine disponibil sau indisponibil într-o zonă, actualizează service-location mapping înainte de modules și links. Un graph poate fi perfect crawlable și totuși să direcționeze utilizatorul către o ofertă care nu mai există.
Cum tratezi paginile cu volum mic
Lipsa traficului nu înseamnă automat că o page este inutilă. Evaluează dacă rezolvă un task local distinct și dacă este conectată logic. Folosește insufficient behavioral data separat de duplicate intent.
Cum tratezi directories locale
Un director extern nu este source owner pentru disponibilitatea serviciului. Dacă afișează o locație veche, marchează conflictul extern și menține graph-ul first-party după registry-ul actual.
Cum verifici modulele automate
Eșantionează target-urile pe service, location, language și lifecycle. Dacă aceeași eroare se repetă, repară regula, nu fiecare link manual. Păstrează reason codes pentru excluderi și fallback.
Claim ledger
- FACT/EVIDENCE: Google recomandă linkuri HTML crawlable și anchor text contextual.
- PRACTITIONER GUIDANCE: local-service linking trebuie să includă service availability, location truth și lifecycle.
- INFERENCE: graph-uri coerente pot ajuta discovery și user navigation.
- NOT PROVEN: un topical-authority score universal derivat din internal links.
Concluzie
În servicii locale, internal linking bun reflectă operațiunile reale. Nu construiește o hartă artificială de keywords, ci un traseu între serviciu, locație și acțiunea următoare. Dacă oferta se schimbă, graph-ul trebuie să se schimbe odată cu ea.
Surse revizuite
- Google Search Central, Link best practices: https://developers.google.com/search/docs/crawling-indexing/links-crawlable
- Google Search Central, Canonicalization: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- Google Search Central, SEO Starter Guide: https://developers.google.com/search/docs/fundamentals/seo-starter-guide
