# Bloguri multiple pe un singur site

Un site poate găzdui mai multe bloguri. Un **site** e un domeniu verificat
plus cheia `pk_…` care îi servește conținutul; un **blog** e o unitate
editorială montată pe o cale de bază sub acel domeniu — cu propria coadă de
subiecte, propriul program, propria temă și propria destinație de livrare.

Motive pentru care ai vrea mai multe:

- **Două limbi pe același domeniu** — română pe `/blog`, engleză pe
  `/en/blog`. Exact exemplul de mai jos.
- **Două audiențe** — un blog de produs pentru cumpărători și unul tehnic
  pentru practicieni, cu cadențe diferite.
- **Două destinații** — un blog integrat în site-ul tău, altul trimis în
  [WordPress](/ro/docs/wordpress).

## Modelul

:::tree

- example.com (site-ul: un domeniu verificat, o cheie pk, un plan)
  - /blog (blog: română, săptămânal, paletă proprie)
    - /blog/facturare-electronica-2026
  - /en/blog (blog: engleză, la două săptămâni, paletă proprie)
    - /en/blog/choosing-an-invoicing-vendor

:::

Livrarea identifică blogul după calea **așa cum apare pe site-ul tău**, iar
calea de bază cea mai lungă câștigă. Deci blogurile pot sta una lângă alta
(`/blog` și `/en/blog`) sau imbricat (`/blog` și `/blog/ro`) — o cerere spre
`/blog/ro/un-articol` ajunge la blogul `/blog/ro`, nu la `/blog`. Căile de
bază sunt unice per site; dacă o refolosești, primești
`409 Base path taken`.

## Ce e per blog și ce e per site

Tabelul ăsta e toată decizia. Dacă lucrurile pe care vrei să le separi sunt
toate în coloana din stânga, folosește două bloguri. Dacă vreunul e în
coloana din dreapta, ai nevoie de două site-uri — vezi penultima secțiune.

| Per blog | Per site |
|---|---|
| Numele și calea de bază | Domeniul verificat și cheia publică `pk_…` |
| Articolele lui și care apar pe acea cale | Profilul de conținut — industrie, **audiență**, **ton**, note de voce, subiecte interzise |
| Coada de subiecte (brief-urile se aprobă și se resping per blog) | Țintele de linkuri — paginile care îți aduc bani |
| Programul: cadență, articole per rulare, fus orar, ora publicării, pauză | Cota de articole și imagini, planul și factura |
| Auto-publicarea | `sitemap.xml` și `rss.xml` (amândouă acoperă toate blogurile site-ului) |
| Imaginile reprezentative pornite/oprite | Identitatea vizuală scanată de pe site-ul tău |
| [Tema MD2](/ro/docs/theming), inclusiv varianta dark | Cheile de API |
| [Webhook-urile](/ro/docs/webhooks) | |
| [Ținta de livrare WordPress](/ro/docs/wordpress) | |

:::callout{severity=warning title="Profilul de conținut e comun — și el e cel care dictează scrisul"}
Industria, audiența, tonul și notele de voce intră în promptul de sistem al
fiecărui pas de generare, pentru fiecare blog al site-ului. Două bloguri pe
un site sunt scrise de aceeași voce internă; ce controlezi per blog e *ce
subiecte se scriu acolo*. Exemplul de mai jos face exact asta, iar secțiunea
„Cum orientezi fiecare blog separat” arată până unde merge.
:::

## Exemplu concret: un blog în română și unul în engleză

`example.com` e al unei firme românești care vinde software de facturare.
Vinde acasă, unde cumpărătorii se uită la termenele impuse de fisc, și
exportă în Europa de Vest, unde cumpărătorii se uită la integrări și la
acordurile de prelucrare a datelor. Același produs, două publicuri care nu
împart aproape nicio căutare.

::::steps

:::step[Creează cele două bloguri]
Pe pagina site-ului, completezi **Numele blogului** și **Calea de bază** și
apeși **Creează blog**, de două ori:

| Nume | Cale de bază | Limbă |
|---|---|---|
| Blog RO | `/blog` | Română |
| Blog EN | `/en/blog` | English |

Numele e intern — etichetează blogul în dashboard, în coada de revizuire și
în payload-urile de webhook. Calea de bază e ce văd cititorii.

**Limba** e singura setare pe care nu o mai poți schimba după aceea. Toți
pașii generării scriu în ea: titlul, intertitlurile, textul, ancorele,
descrierea meta. Ciorna e verificată după regulile de stil ale acelei limbi,
așa că un articol în română e prins pe „În era digitală”, iar unul în engleză
pe „In today's fast-paced world”. Un blog servește o singură limbă; de aceea
schimbarea ei după primul articol e refuzată: articolele existente ar
dispărea de pe site. Fă un al doilea blog: exact despre asta e pagina de
față.
:::

:::step[Montează fiecare blog pe site]
Fiecare blog are nevoie de pagina lui pe domeniul tău și de snippet-ul lui.
Vezi „Cum servești ambele bloguri”, mai jos, pentru regulile de rutare — e
pasul pe care lumea îl greșește.
:::

:::step[Dă-i fiecăruia program și paletă proprii]
Două audiențe rareori vor același ritm. O împărțire plauzibilă:

| Setare | `/blog` (RO) | `/en/blog` (EN) |
|---|---|---|
| Cadență | săptămânal, 1 articol | la două săptămâni, 1 articol |
| Fus orar | `Europe/Bucharest` | `Europe/Berlin` |
| Ora publicării | 8 | 10 |
| Auto-publicare | pornită — citești română și ai încredere în rezultat | oprită — fiecare articol e citit întâi |
| Temă | paleta site-ului | paleta site-ului |

Blogurile pot împărți o paletă, dar nu sunt obligate. Dacă blogul în engleză
stă pe o parte a site-ului stilizată altfel, dă-i cele cincisprezece
token-uri ale lui, din pagina blogului.
:::

:::step[Alimentează fiecare blog cu subiectele lui]
Fiecare blog își trage brief-urile din coada **lui**. **Planifică subiecte**
pe blogul în română și pe cel în engleză produce două liste independente,
iar tu aprobi separat în fiecare. Secțiunea următoare e despre ce aprobi.
:::

:::step[Trimite rezultatul unde îi e locul]
Webhook-urile și ținta WordPress sunt per blog, așa că articolele în română
pot merge într-un WordPress (sau într-o automatizare) și cele în engleză în
altul, fără niciun filtru scris de tine.
:::

::::

## Conținut diferit pentru audiențe diferite

Rostul împărțirii e ca cele două bloguri să nu publice traduceri unul din
celălalt — ci articole diferite, pentru că cititorii caută lucruri diferite.

::::compare{title="Două publicuri, un singur produs"}

:::option[Blog RO — /blog]{key=A severity=info}

**Cititorul:** patronul sau contabilul unei firme românești de 5–50 de
oameni, deja obligat să raporteze electronic, care compară unelte în lei.

**Publică:** explicații de termene, ghiduri pas cu pas prin regulile locale
de raportare, prețuri în RON, liste de verificare înainte de o scadență.

**Linkuiește spre:** `/preturi`, `/functionalitati`, centrul de ajutor în
română.

:::

:::option[Blog EN — /en/blog]{key=B severity=success}

**Cititorul:** un responsabil de operațiuni sau achiziții din Germania ori
Olanda, în plină evaluare de furnizori, care n-a auzit niciodată de firma
ta.

**Publică:** ghiduri de integrare, migrări de la furnizorul actual,
întrebări de GDPR și prelucrare a datelor, materiale de tip „cum evaluezi un
furnizor".

**Linkuiește spre:** `/pricing`, `/integrations`, pagina de securitate.

:::

::::

Concret, cele două cozi de subiecte n-ar semăna deloc:

| `/blog` (RO) | `/en/blog` (EN) |
|---|---|
| Termenele de raportare din 2026, pe luni | How to evaluate an invoicing vendor in 30 days |
| Ce faci când o factură e respinsă | Migrating 40,000 invoices without downtime |
| Facturare pentru PFA: ce se schimbă | GDPR and invoice data: what your DPA must say |
| Cât costă, în RON, o eroare de raportare | Connecting invoicing to your ERP: three patterns |

Nimic din tabelul ăsta nu e impus de produs — e decizia editorială pe care o
iei când aprobi subiecte în fiecare coadă. Ce îți dă produsul e că cele două
cozi, programe și fluxuri de revizuire nu se ating niciodată.

:::callout{severity=info title="Planificatorul evită repetițiile per blog, nu per site"}
Planificarea de subiecte evită titlurile care există deja **pe acel blog**.
Două bloguri de pe același site pot primi deci aceeași idee — exact ce vrei
când unul o va scrie în română și celălalt în engleză, și ceva de urmărit
când amândouă sunt în aceeași limbă.
:::

## Cum orientezi fiecare blog separat

Profilul care dictează *cum* e scris un articol e per site, așa că direcția
editorială per blog trece prin brief-uri:

- **Aprobă selectiv.** Coada de subiecte e adevăratul control per blog.
  Respinge ce aparține celuilalt blog, în loc să-l lași să ruleze.
- **Titlul și unghiul sunt respectate.** Un brief scris de tine are titlu,
  cuvânt cheie țintă și unghi, iar generatorul planifică secțiunile exact
  pentru acel subiect pornind de la ele — deci limba și încadrarea
  brief-ului trec în articol. În dashboard e câmpul **Scrie despre…** din
  onboarding; prin API e
  `POST /v1/orgs/{orgId}/blogs/{blogId}/briefs` cu
  `{"title": …, "target_keyword": …, "angle": …}` (autentificat cu sesiune,
  ca tot restul API-ului de dashboard).
- **Ține limba în afara notelor de voce.** Sunt la nivel de site și intră în
  fiecare prompt, pentru fiecare blog — un „scrie în română” acolo îți
  întoarce și blogul în engleză. Pune limba în brief, unde afectează un
  singur articol.
- **Adaugă ambele versiuni de limbă ale paginilor care îți aduc bani ca
  ținte de linkuri.** Scriitorul primește toată lista site-ului, cu
  cuvintele de ancoră ale fiecărei ținte, și alege contextual. Dă-i lui
  `/preturi` ancore în română și lui `/pricing` ancore în engleză și va fi
  aleasă cea potrivită; dacă lași în listă doar pagina în engleză, articolele
  tale în română vor linkui spre ea.

## Cum servești ambele bloguri

Fiecare blog e o montare separată. Indiferent de integrarea aleasă, o faci o
dată per blog.

**JS SDK** — un container per pagină, iar SDK-ul se leagă de **primul**
element `[data-baas-blog]` pe care îl găsește, deci cele două snippet-uri
stau pe două pagini diferite:

```html
<!-- pagina servită la /blog -->
<div data-baas-blog data-key="pk_CHEIA_TA" data-base-path="/blog"
     data-api="https://api.dailysmith.com"></div>
<script src="https://api.dailysmith.com/v1/sdk/blog.js" async></script>
```

```html
<!-- pagina servită la /en/blog -->
<div data-baas-blog data-key="pk_CHEIA_TA" data-base-path="/en/blog"
     data-api="https://api.dailysmith.com"></div>
<script src="https://api.dailysmith.com/v1/sdk/blog.js" async></script>
```

Aceeași cheie — ea identifică site-ul, nu blogul. Fiecare shell trebuie
servit pentru calea lui de bază *și pentru tot ce e sub ea*, de exemplu pe
Netlify:

```
/blog/*      /blog/index.html      200
/en/blog/*   /en/blog/index.html   200
```

**Edge proxy** — o regulă per cale de bază, aceeași cheie (mai jos e
`_redirects` de Netlify; [pagina de proxy](/ro/docs/install-proxy) are aceeași
regulă pentru Cloudflare, Vercel, nginx și Caddy):

```
/blog           https://api.dailysmith.com/v1/render/PK/blog             200
/blog/*         https://api.dailysmith.com/v1/render/PK/blog/:splat      200
/en/blog        https://api.dailysmith.com/v1/render/PK/en/blog          200
/en/blog/*      https://api.dailysmith.com/v1/render/PK/en/blog/:splat   200
```

Ordonează regulile astfel încât calea mai specifică să se potrivească prima
— sau, pe o platformă care le evaluează în ordinea din fișier, pune
`/en/blog` înainte.

**Prerender static** — o rulare per blog:

```
npx baas-blog prerender --key pk_CHEIA_TA --api https://api.dailysmith.com --base /blog --out ./public/blog
npx baas-blog prerender --key pk_CHEIA_TA --api https://api.dailysmith.com --base /en/blog --out ./public/en/blog
```

Ca să descoperi montările programatic — util într-un script de build care nu
trebuie să le aibă hardcodate — întreabă
[delivery API](/ro/docs/delivery-api):

```
GET /v1/delivery/{publicKey}/blogs
→ {"blogs":[{"name":"Blog RO","base_path":"/blog","default_locale":"ro"},
            {"name":"Blog EN","base_path":"/en/blog","default_locale":"en"}]}
```

## SEO peste două bloguri

- **`sitemap.xml` și `rss.xml` sunt la nivel de site.** Un singur sitemap
  acoperă indexul fiecărui blog și fiecare articol publicat, deci referi un
  singur URL din `robots.txt` și ambele bloguri sunt crawl-uite. Reversul:
  feed-ul RSS le amestecă pe amândouă — dacă vrei un feed per limbă,
  construiește-l din
  `GET /v1/delivery/{publicKey}/posts?base_path=…`.
- **Canonical-urile sunt per articol** și arată mereu spre calea proprie a
  articolului, sub calea de bază a blogului lui, deci cele două bloguri nu
  se concurează niciodată pe același URL.
- **hreflang îl adaugi tu.** Nimic nu leagă blogul în română de cel în
  engleză ca alternative — sunt bloguri separate, cu articole separate, nu
  traduceri unul din celălalt. Dacă publici totuși o pereche echivalentă,
  pune etichetele `<link rel="alternate" hreflang="…">` în shell-ul tău.
- **Un selector de limbă e doar un link** între `/blog` și `/en/blog`, pus
  în navigația site-ului tău.

:::callout{severity=warning title="Paginile randate pe server declară engleză, deocamdată"}
Fiecare articol e stocat sub locale-ul site-ului, care e `en` pentru toate
site-urile în acest moment — locale-ul per blog nu se poate seta încă. Două
consecințe pentru o configurație bilingvă, invizibile pentru cititori și
vizibile pentru crawlere:

- Paginile servite prin [edge proxy](/ro/docs/install-proxy) sau prin
  [prerender static](/ro/docs/install-prerender) poartă `<html lang="en">`
  chiar dacă articolul e în română. Pe calea cu [JS SDK](/ro/docs/install-sdk)
  problema nu apare — contează atributul `lang` de pe pagina ta, deci pune
  `lang="ro"` pe cea în română.
- Nu trimite `?locale=ro` către endpoint-urile de render sau de delivery.
  Filtrează după locale-ul stocat, deci îți întoarce un index gol în loc de
  articolele tale în română. Omite parametrul și fiecare blog servește tot
  ce are.
:::

## Când răspunsul corect e un al doilea site

Două bloguri împart un profil, un set de ținte de linkuri, o cotă și o
factură. Treci la un al doilea site când:

- **Domeniile diferă** — `example.ro` și `example.com` sunt două site-uri
  prin definiție; un site înseamnă un domeniu verificat.
- **Vocea chiar diferă.** Două branduri, sau un brand de consum și unul
  tehnic, au nevoie de două profiluri de conținut — iar profilul e per site.
- **Paginile care aduc bani diferă.** Țintele de linkuri sunt per site, deci
  două produse cu pâlnii separate stau mai curat separat.
- **Vrei facturare și cote separate**, de exemplu un site per client, într-o
  agenție.

Costul e o a doua verificare, o a doua scanare de profil și un al doilea
abonament. În interiorul unui singur domeniu, însă, blogurile sunt singura
împărțire posibilă: o organizație nu poate avea două site-uri pe același
domeniu.

## Limite și întreținere

Numărul de bloguri per site face parte din ce vinde fiecare plan — 1 pe
Trial și pe Starter, 3 pe Growth, nelimitat pe Scale — alături de o alocare
de locale. Așa cum spune [pagina de planuri](/ro/docs/billing), cota de
articole e singura limită impusă efectiv azi; numărul de bloguri ține de
împachetare. Cota e oricum per site, deci un al doilea blog consumă din
aceeași alocare lunară ca primul — două bloguri cu câte patru articole pe
lună au nevoie de un plan care acoperă opt.

Două lucruri legate de bloguri sunt fără drum de întoarcere azi, deci
hotărăște-le înainte să apeși **Creează blog**:

- **Calea de bază e fixă după creare.** Numele, auto-publicarea și imaginile
  reprezentative se pot edita; calea nu. S-o schimbi înseamnă să creezi un al
  doilea blog — iar articolele rămân la primul.
- **Blogurile nu se pot șterge.** Ca să retragi unul, pune-i programul pe
  pauză și scoate-i montarea din site. Articolele lui devin inaccesibile în
  clipa în care calea nu mai răspunde pe domeniul tău.