La tecnologia dietro SEOJuice (e perché è noiosa)

In breve: La maggior parte dei post sul tech stack risponde alla domanda sbagliata. La parte utile del tech stack di SEOJuice non è quale logo appare su StackShare, ma come seojuice.com impedisce che crawling, scoring, fatturazione, suggerimenti di link e pagine indicizzabili si rompano a vicenda.

L’elenco dello stack è la parte meno interessante del tech stack di SEOJuice

seojuice.com non è nato come una mega-piattaforma. È nato dallo stesso problema che vedevo di continuo in mindnow e su vadimkravcenko.com: i team pubblicavano buon contenuto, poi lasciavano link interni mancanti, metadati obsoleti, pagine orfane e fix lenti a marcire in backlog per mesi. Il tech dietro SEOJuice quindi non è ottimizzato per le slide da conferenza. È ottimizzato per lavori di pulizia ripetibili che non dovrebbero richiedere un altro sprint SEO.

Ecco perché un semplice elenco di stack sembra debole. StackShare ti dà i nomi. Può mostrarti un profilo veloce (la risposta pubblica attuale). Bene. Ma i nomi non dicono se un prodotto sopravvive a crawl lenti, richieste bloccate, cache miss, input errati, edge case di fatturazione o failure parziali.

Ho costruito abbastanza sistemi per clienti in mindnow da sapere che l’architettura raramente fallisce nel percorso felice. Fallisce alle 2 di notte — quando una coda si intasa, un crawler viene bloccato o un “semplice” aggiornamento di contenuto cambia l’URL canonico su 400 pagine.

Gli strumenti SEO sono disordinati perché stanno fra intento umano, HTML del sito, crawler, API di terze parti, job schedulati e UI di prodotto. Un marketer clicca un pulsante e si aspetta raccomandazioni utili. Dietro quel pulsante il sistema potrebbe dover recuperare pagine, analizzare link, rilevare duplicati, assegnare punteggi, salvare evidenza, rispettare limiti e mostrare l’avanzamento senza mentire.

Quindi questo articolo non è un catalogo di vendor. È una mappa dei failure mode. Il vero tech stack di SEOJuice è l’insieme di decisioni che mantiene economica la manutenzione SEO noiosa.

Versione corta: cosa deve fare lo stack di SEOJuice

Se sei qui per la risposta diretta, eccola: il tech stack di SEOJuice si capisce meglio per ruolo, non per brand. I singoli servizi possono cambiare. Le responsabilità no.

Quella tabella è meno “wow” di una parete di loghi. Ottimo. SEOJuice deve essere noioso dove “noioso” è la parola giusta: recuperabile, osservabile e facile da ragionare.

Gap SERP: i risultati attuali si fermano prima della risposta utile

StackShare risponde al “cosa”, non al “perché”

StackShare è utile per una consultazione rapida. Soddisfa la query letterale. Ma chi cerca seojuice tech stack di solito vuole più di curiosità su vendor. Vuole sapere se il prodotto è tenuto insieme da uno script giocattolo o da decisioni di engineering sensate.

La parte mancante è il fit. Perché un prodotto SEO ha bisogno di job in background? Perché separare le pagine pubbliche dagli schermi dell’app? Perché salvare i timestamp di crawl? Perché i limiti devono comparire come comportamento di prodotto invece che come failure casuali? È la parte che un profilo di stack non può spiegare.

Stripe mostra come i sistemi maturi pensano ai limiti

Il blog engineering di Stripe non parla di tooling SEO, ma la sua mentalità sui rate limit si applica bene. Paul Tarjan ha scritto:

“I nostri rate limit per le richieste scattano costantemente. Solo questo mese hanno respinto milioni di richieste.”

Quella frase conta perché tratta i limiti come comportamento normale di produzione, non come patch d’emergenza. Software ricco di crawl ha bisogno dello stesso mindset. Un singolo sito grande non deve rallentare ogni account. Un retry ripetuto non deve martellare il server di un cliente. I limiti di terze parti non devono trapelare in UI come errori misteriosi.

Vercel mostra il valore di rimuovere attrito

La scrittura di Vercel è utile per un altro motivo: la velocità di rilascio. Lee Robinson l’ha riassunta così:

“Il tuo vantaggio più grande può essere la rapidità con cui rilasci, ascolti feedback e iteri.”

Sottoscrivo, con una condizione. La velocità serve solo quando il sistema è abbastanza semplice da fare rollback, osservare e ragionare. Altrimenti la rapidità diventa un modo più elegante di creare incident.

Principio 1: static-first dove conta per Google, app-like dove lavorano gli utenti

seojuice.com non deve trattare tutte le superfici allo stesso modo. Pagine pubbliche, post del blog, documentazione e landing page hanno bisogno di HTML veloce e metadati stabili. Le schermate autenticate del prodotto hanno bisogno di interattività, filtri, stati, dati utente e memoria di workflow.

Sono lavori diversi.

Le superfici SEO pubbliche devono produrre HTML crawlable al primo load, title, description, canonical e link interni prevedibili. È lì che contano le pratiche static-first per HTML e rendering app. A Google non serve la tua dashboard. Agli utenti sì. Confondere le due superfici è come ritrovarsi a ricostruire tutto perché una route aveva il modello di rendering sbagliato.

La dashboard può comportarsi più da applicazione. Può mostrare stato del progetto, filtri, suggerimenti ignorati, stato di fatturazione, avanzamento del crawl e azioni interattive. Quella superficie non deve posizionarsi per “UI di scoring salute pagina” (non è una superficie di ranking). Deve aiutare l’utente a finire un lavoro senza aspettare i crawler.

Il dominio condiviso non è la parte interessante. La parte interessante è rifiutarsi di imporre un unico modello di rendering a ogni route. Le pagine pubbliche devono essere indicizzabili e stabili. Gli schermi privati devono essere utili e stateful.

Principio 2: crawler e scoring non devono stare sul path della richiesta

Il pulsante deve salvare il progetto. Non deve diventare una trattativa con l’host WordPress lento di qualcuno.

Quella frase spiega gran parte del tech stack di SEOJuice. Quando un utente crea o aggiorna un progetto, l’app deve salvare la richiesta, mettere in coda il lavoro di crawl e restituire uno status chiaro. I crawler possono poi recuperare le pagine rispettando i limiti. I parser possono estrarre title, heading, canonical, body, link interni e dettagli di risposta. Lo scoring può partire dopo che esiste abbastanza contenuto.

La UI deve leggere lo stato corrente. Non deve fingere che tutto sia istantaneo.

Qui entrano in gioco le code. Il crawling è lento rispetto alle azioni normali di una web app. Alcuni siti rispondono in 80 ms. Altri in otto secondi. Alcuni bloccano user-agent sconosciuti. Altri fanno cinque redirect prima di servire una pagina. Alcuni servono HTML diverso in base agli header. Se quel lavoro avviene durante la richiesta normale — sincrono, bloccante, sul click dell’utente — il prodotto diventa lento quanto il sito peggiore del crawl.

Il processing in background rende anche i retry più sicuri. Un fetch fallito può essere riprovato con un budget. Un URL bloccato può essere marcato. Un crawl può mettersi in pausa. Uno scoring può attendere contenuto parsato invece di indovinare.

“Ci sono solo due cose difficili in Informatica: invalidazione della cache e dare i nomi alle cose.”

La battuta di Phil Karlton si ripete perché resta vera. Nel software SEO, una cache stantia non è solo un bug tecnico. Può voler dire consigliare link da una pagina che non esiste più, mancare una pagina pubblicata ieri o dire a un utente che un title va bene dopo che il CMS l’ha cambiato.

L’architettura sbagliata sembra veloce finché non mente

I risultati finti istantanei sono pericolosi. Se le raccomandazioni appaiono prima che il crawl sia finito, il prodotto può sembrare rapido per cinque minuti. Poi la fiducia crolla. Un utente vede suggerimenti basati su dati vecchi e inizia a chiedersi cos’altro sia sbagliato.

Mi sono sbagliato su questo per anni (amavo troppo le interfacce “istantanee”). Ora preferisco mostrare progresso onesto anziché certezza inventata. “Abbiamo trovato 180 pagine e ne abbiamo valutate 92 finora” batte una dashboard piena basata su ipotesi.

Principio 3: i rate limit sono comportamento di prodotto, non decorazione backend

I rate limit vengono di solito descritti come prevenzione di abuso. Per SEOJuice definiscono anche equità, affidabilità e fiducia del cliente.

Un singolo sito grande non deve rallentare tutti gli altri account. Retry ripetuti non devono colpire per sempre il server di un cliente. Burst API non devono trasformarsi in failure UI casuali. I limiti dei piani di pagamento devono sembrare promesse chiare, non trappole nascoste.

I limiter stile Redis sono utili qui, ma il limiter stesso non deve diventare un single point of failure di prodotto. La seconda lezione di Stripe di Tarjan è quella che mi interessa di più:

“Assicurati che, se ci fossero bug nel codice di rate limiting (o se Redis andasse giù), le richieste non ne risentano.”

È l’istinto giusto. Se il limiter fallisce, il lavoro normale deve degradare in modo sicuro dove possibile. Magari il crawling rallenta. Magari una coda si ferma. Magari la UI mostra uno status in ritardo. Quello che non deve succedere è un outage totale perché il layer di protezione è diventato più fragile di ciò che proteggeva.

I rate limit devono anche essere abbastanza visibili da farsi capire dagli utenti. “Il tuo crawl è in coda perché questo sito è già in fetch” è meglio di uno spinner infinito.

Principio 4: i dati SEO hanno bisogno di storage noioso e stato spiegabile

L’automazione SEO perde fiducia quando non può spiegare perché esiste una raccomandazione.

Ciò significa che SEOJuice ha bisogno di stato durevole per le cose noiose: account, progetti, siti, URL crawlati, contenuto delle pagine parsate, opportunità di link, stato delle raccomandazioni, suggerimenti ignorati, azioni utente, timestamp di crawl e marker di freschezza. Nulla di glamour. Tutto fondamentale.

I database noiosi sono sottovalutati. Le raccomandazioni SEO hanno bisogno di memoria.

Se una pagina è cambiata ieri, un utente deve sapere se un suggerimento si basava sul crawl di ieri o di un mese fa. Se una raccomandazione è stata scartata, il sistema deve ricordarlo. Se un URL è stato reindirizzato, il prodotto non deve continuare a suggerire link alla vecchia posizione. Se una pagina è sparita, le raccomandazioni correlate devono scadere.

Qui dare i nomi diventa verità di prodotto. “Pagina”, “URL”, “canonical” e “raccomandazione” sembrano ovvi finché non entrano redirect, duplicati e template CMS. Dare nomi sbagliati crea modelli mentali sbagliati. I modelli sbagliati creano ticket di supporto.

Lo strato di storage non deve essere furbo — deve essere spiegabile. Quando SEOJuice suggerisce un link interno, il prodotto deve poter rispondere: da quale pagina, a quale pagina, basato su quale crawl, con quale anchor context e con che stato attuale?

Principio 5: lo stack deve rendere sicuri i piccoli rilasci

La lezione di Vercel sulla velocità di rilascio è utile, ma SEOJuice non ha bisogno del teatro da piattaforma. Ha bisogno di cicli di feedback brevi.

I rilasci piccoli sono più facili da rivedere. Log chiari rendono più facile trovare job rotti. I rollback riducono la paura. I feature flag aiutano quando il rischio è alto. La revisione manuale è ancora necessaria vicino alla logica di raccomandazione sensibile, soprattutto quando una modifica di scoring potrebbe influenzare molti utenti in una volta.

Nota a margine: prima davo troppo valore ad architetture “smart” qui. Sembrava responsabilità. Di solito rende solo più lento il fix successivo.

Il percorso di rilascio deve rendere economico spedire fix di contenuto, UX, billing e miglioramenti di scoring. Non vuol dire essere spericolati. Significa che i cambiamenti sono abbastanza piccoli da capire e abbastanza reversibili da dormire dopo il deploy.

Lo stesso vale per l’automazione del linking interno. Un motore di raccomandazione migliora con il feedback. Gli utenti ignorano alcuni suggerimenti. Ne accettano altri. Rivelano edge case invisibili nei dati di test. Lo stack deve permettere che quelle lezioni diventino cambiamenti di prodotto rapidamente.

Cosa decidiamo intenzionalmente di non ottimizzare

Siamo onesti: alcune cose non valgono l’ottimizzazione.

Il tech stack di SEOJuice non deve impressionare gli ingegneri a costo di confondere gli utenti. Guadagna fiducia quando il prodotto si comporta in modo prevedibile: salva il progetto, esegue il crawl in sicurezza, mostra l’avanzamento, spiega le raccomandazioni, ricorda le decisioni e si riprende dai failure.

Sembra ordinario perché lo è. L’ordinario è il punto.

Allora, qual è davvero il tech stack di SEOJuice?

Il tech stack di SEOJuice è un insieme di ruoli di prodotto: superfici frontend per pagine pubbliche e schermate app, layer applicativo backend per account e raccomandazioni, storage durevole per stato SEO, code per crawling e scoring, cache e layer di rate limit per velocità e protezione, monitoring per job falliti e retry, e un percorso di deploy che mantiene piccoli i rilasci.

Se i nomi dei vendor cambiano, quella descrizione deve restare valida. I ruoli sono più stabili dei singoli servizi.

Le pagine pubbliche devono essere crawlable e veloci. Le schermate app devono essere reattive e stateful. I crawler necessitano di isolamento. Lo scoring ha bisogno di evidenza salvata. La fatturazione richiede stato account durevole. I limiti hanno bisogno di fallback sicuri. I log devono rendere i failure visibili prima che siano gli utenti a spiegarli.

Questo articolo non è un documento di architettura interna e non pretende di esserlo. La trasparenza utile è il modello operativo: static-first dove conta per Google, queue-backed dove i crawler sono lenti, fail-safe dove i limiti proteggono il prodotto e storage noioso dove le decisioni sui link devono essere spiegate.

FAQ

Qual è il tech stack di SEOJuice?

È un mix di delivery di pagine pubbliche, infrastruttura applicativa, storage persistente, job in background, caching, rate limit e monitoring. I nomi dei servizi contano meno delle responsabilità: pagine crawlable, schermate prodotto reattive, stato SEO durevole, crawl sicuri, raccomandazioni spiegabili e failure osservabili.

Perché non pubblicate ogni nome di servizio interno?

Un elenco di vendor invecchia e può creare la trasparenza sbagliata. Sapere un logo non dice come il sistema gestisce crawl, failure, retry, limiti e stato delle raccomandazioni. La risposta utile è architetturale, non decorativa.

SEOJuice è costruito per Googlebot o per gli utenti?

Per entrambi, ma non sulla stessa superficie. Le pagine pubbliche sono costruite per essere crawlable di default. La dashboard è costruita per i workflow utente: progetti, filtri, stato crawl, raccomandazioni e azioni.

Perché un tool SEO ha bisogno di code?

Crawling, parsing e scoring sono lenti rispetto alle azioni utente normali. Le code mantengono l’app reattiva, rendono i retry più sicuri e impediscono che un sito lento blocchi tutti gli altri.

Vuoi togliere dal backlog il lavoro SEO noioso?

Se il tuo team continua a rimandare link interni, metadati obsoleti, pagine orfane e pulizia dei contenuti, SEOJuice è costruito proprio per quel gap. Lo stack è noioso di proposito — così la manutenzione può avvenire senza trasformarsi in un altro progetto di engineering.