Arhitectură pentru un site de prezentare livrabil în 3 zile

TL;DR

• Un site de prezentare livrat rapid cere standardizare: design system, componente reutilizabile și un model clar de conținut.
• Static-first (SSG) + CDN + formulare serverless oferă performanță, costuri mici și mentenanță redusă.
• SEO local nu e „un plugin”: e un set de decizii (schema, NAP, pagini de locație, sitemap, redirects) plus verificări automate.
• Emailul pe domeniu are gotchas reale (SPF/DKIM/DMARC). Automatizează-le sau vei pierde timp în suport.

Problema: viteză de livrare fără compromisuri

Când promiți „gata în 3 zile”, riscul nu e doar să scrii cod repede. Riscul e să nu poți repeta procesul pentru următorul client. Un site de prezentare pentru servicii locale (cabinete, saloane, instalatori) are aceleași cerințe de bază:

• pagini: Acasă, Servicii, Despre, Contact (+ uneori Portofoliu/Prețuri)
• mobile-first, scor bun în Core Web Vitals
• formulare de contact funcționale + protecție anti-spam
• SEO local: NAP consistent (Name/Address/Phone), map embed, schema, pagini indexabile
• email profesional: [email protected]

Dacă tratezi fiecare proiect ca un „one-off”, vei ajunge să rezolvi aceleași bug-uri de 10 ori. Abordarea care scalează este să proiectezi un template tehnic și un pipeline de configurare.

Soluția: un blueprint repetabil (SSG + config + checklist)

Pentru un site de prezentare livrat rapid, modelul care funcționează cel mai des este:

1. Static-first: Next.js (SSG) / Astro / Eleventy.
2. Conținut ca date: JSON/YAML/MDX, validat cu un schema.
3. Deployment automat: build → preview → production.
4. Observabilitate minimă: uptime + logs pentru formulare.

De ce static-first? Pentru că majoritatea site-urilor de prezentare sunt read-mostly. Dacă nu ai nevoie de autentificare sau conținut dinamic complex, SSR permanent e un cost operațional inutil.

Referințe utile:

• Web.dev despre Core Web Vitals: https://web.dev/vitals/
• Documentația Next.js (SSG / routing / metadata): https://nextjs.org/docs

Implementare: model de conținut tipizat + componente

Un singur fișier de configurare (care reduce discuțiile)

În loc să „hardcodezi” date în componente, folosește un config central. Într-un site de prezentare, 80% din schimbări sunt: nume firmă, servicii, program, adresă, telefon, linkuri.

// site.config.ts
import { z } from "zod";

export const SiteConfigSchema = z.object({
  brand: z.object({
    name: z.string().min(2),
    domain: z.string().min(4),
    logoUrl: z.string().url().optional(),
  }),
  contact: z.object({
    phone: z.string().min(6),
    email: z.string().email(),
    address: z.string().min(5),
    city: z.string().min(2),
    lat: z.number(),
    lng: z.number(),
  }),
  businessHours: z.array(
    z.object({ day: z.string(), opens: z.string(), closes: z.string() })
  ),
  services: z.array(
    z.object({
      name: z.string(),
      slug: z.string(),
      description: z.string().min(30),
    })
  ),
  seo: z.object({
    title: z.string(),
    description: z.string().min(50),
    locale: z.string().default("ro_RO"),
  }),
});

export type SiteConfig = z.infer<typeof SiteConfigSchema>;

De ce Zod? Pentru că validezi input-ul înainte să ajungă în build. Un site de prezentare cu o adresă lipsă nu e un bug „vizual”; e o problemă de conversie.

Componente atomic + layout-uri fixe

Ține un set mic de layout-uri:

• MarketingLayout (hero + secțiuni)
• ServiceLayout (beneficii + CTA + FAQ opțional)
• ContactLayout (map + form + NAP)

Apoi construiești secțiuni reutilizabile:

• Hero, TrustBar, ServiceGrid, Testimonial, FAQ, Footer

Cheia pentru livrare rapidă: nu oferi „design nelimitat”. Oferă variante controlate (ex: 3 stiluri de hero, 2 variante de card). Într-un site de prezentare, consistența bate creativitatea ad-hoc.

Pipeline: preview links, checks și livrare fără stres

Build + deploy cu verificări obligatorii

Un pipeline minimal:

1. lint + typecheck
2. unit pentru helpers (slugify, sitemap generation)
3. build + bundle analysis (opțional)
4. lighthouse-ci pe pagini cheie

# .github/workflows/ci.yml
name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test
      - run: npm run build

Un site de prezentare nu are voie să „pice” la deploy pentru un typo în config. Automatizarea e diferența dintre 3 zile și 7.

Preview environment pentru feedback rapid

Folosește preview deployments (Vercel/Netlify/Cloudflare Pages). Clientul vede schimbările fără să atingi producția. Pentru un site de prezentare, asta reduce ping-pong-ul pe capturi de ecran.

SEO local: lucruri tehnice care chiar contează

SEO local e ușor de subestimat. În realitate, pentru un site de prezentare local, micile detalii sunt multiplicatori.

1) Schema.org pentru LocalBusiness

Google citește mai bine entitatea business-ului dacă ai structured data.

Referință: https://schema.org/LocalBusiness

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Nume Firmă",
  "telephone": "+40...",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Str...",
    "addressLocality": "Oraș",
    "addressCountry": "RO"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 44.43,
    "longitude": 26.10
  },
  "url": "https://exemplu.ro"
}
</script>

2) NAP consistent + pagină de contact „completă”

Pe un site de prezentare, pagina Contact nu e o formalitate. Include:

• telefon click-to-call
• adresă copy-friendly
• program
• Google Maps embed
• link către profilul Google Business (dacă există)

3) Sitemap + robots + redirects

Checklist tehnic:

• sitemap.xml generat la build
• robots.txt fără blocări accidentale
• redirect 301 pentru www vs non-www
• canonical setat corect

Email profesional: SPF/DKIM/DMARC (gotchas reale)

Mulți cred că „email pe domeniu” înseamnă doar creare inbox. În practică, livrabilitatea e o problemă. Pentru un site de prezentare care colectează lead-uri, emailul trebuie să ajungă în inbox, nu în spam.

Minimul recomandat:

• SPF: autorizează serverele care trimit
• DKIM: semnează mesajele
• DMARC: policy + rapoarte

Documentație bună (Google): https://support.google.com/a/answer/33786

Gotcha: dacă folosești un provider pentru formulare (ex: trimiți notificări), SPF/DKIM trebuie să includă și acel provider. Altfel, lead-urile devin „fantome”.

Formulare: serverless + anti-spam fără fricțiune

Pentru un site de prezentare static, ai câteva opțiuni:

• Netlify Forms / Formspark / Formspree
• endpoint serverless (Cloudflare Workers / Vercel Functions)

Un endpoint minimal ar trebui să aibă:

1. rate limiting
2. honeypot field
3. validation (Zod)
4. log + alert pe erori

// pseudo: serverless handler
if (honeypotFilled) return 200;
if (!rateLimitOk(ip)) return 429;
const parsed = ContactSchema.safeParse(body);
if (!parsed.success) return 400;
await sendMail(parsed.data);
return 200;

What I learned (și ce aș face diferit)

• Standardizarea câștigă: un site de prezentare livrat rapid are nevoie de „opinii” în cod (decizii implicite), altfel fiecare proiect devine negociere.
• Validează conținutul ca pe input de API. Greșelile de copy sunt inevitabile; build-ul trebuie să le prindă.
• SEO local e un set de fișiere și reguli, nu un task de „final”. Când îl pui în checklist de build, nu-l uiți.

Gotchas: lucruri care îți pot strica deadline-ul

• Fonturi: prea multe variante → payload mare → Lighthouse scade.
• Imagini: fără srcset/optimizare → LCP slab. Folosește pipeline de optimizare.
• Canonical greșit (mai ales în preview) → indexare ciudată.
• DNS pentru email: propagare + configurări incomplete → suport neplanificat.

Un exemplu practic: cum aș structura livrarea în 3 zile

1. Ziua 1: colectare date (servicii, poze, NAP), completare config, alegere variantă de template.
2. Ziua 2: implementare pagini + optimizări (imagini, schema, sitemap), preview pentru feedback.
3. Ziua 3: DNS, email (SPF/DKIM/DMARC), redirecturi, verificări Lighthouse, push production.

Pentru un site de prezentare, această secvență funcționează pentru că reduce dependențele: design-ul e controlat, iar riscurile (DNS/email) sunt împinse spre final, cu checklist clar.

Call-to-action (util, nu promo)

Dacă vrei să-ți simplifici propriul proces, începe prin a-ți crea un „starter” intern: un template + un site.config.ts tipizat + un checklist de DNS/SEO. Iar dacă ai nevoie de un exemplu real de pachet „site complet în 3 zile” (hosting, email și SEO local incluse), poți analiza oferta și mesajele de produs de la https://vreau-site.ro ca studiu de poziționare și scope.

Originally about site de prezentare.