Un Client WordPress locale, con servizi remoti solo dove aggiungono valore.
L’architettura SuperRankSEO separa responsabilità locali e remote: il Client WordPress possiede stato e applicazione di molte funzioni; il Control governa entitlement e configurazioni centrali; Google e altri provider restano fonti o servizi esterni. Questa separazione permette a Free di mantenere una base local-first e a PRO di aggiungere intelligence e automazione senza confondere i confini.
Lo stesso workflow attraversa domini con responsabilità diverse
Separare i piani evita di descrivere come locale ciò che dipende da un provider esterno e, al contrario, evita di rendere remota una funzione che può continuare a vivere nel sito.
WordPress Client
Contenuti, metadata, Schema, linking, baseline, code/stato locale e applicazione delle modifiche secondo il modulo proprietario.
Local execution plane
Control
Entitlement PRO, profili, configurazioni e governance di servizi centrali senza trasformare ogni installazione in un deposito di secret.
Control plane
Google data plane
Search Console, URL Inspection e GA4 forniscono segnali autorizzati dall’amministratore e mantengono semantica/availability proprie.
External data plane
Provider services
AI, lettura competitor, entity resolution o altri servizi entrano solo nei workflow che li richiedono e restano dipendenze dichiarate.
External service plane
Il dato viene raccolto una volta, poi riusato senza perdere la provenienza
Search Console e GA4 possono alimentare più workflow; lo stato locale può condizionare sitemap e monitoring; Change History può riunire eventi diversi. Il riuso è utile solo se ogni modulo conserva il significato originale del dato.
Stato locale
Il Client legge contenuto, metadata, indexability, linking, Schema e altre fonti WordPress.
Dati esterni
OAuth o provider specifici aggiungono query, analytics, index state o altri segnali.
Decisione
Action Center o il modulo specializzato combinano solo i segnali pertinenti alla domanda operativa.
Applicazione
Il modulo proprietario esegue la modifica nel proprio dominio, con i controlli previsti.
Osservazione
Sentinel, Launch Monitor, Index Alerts, Change History o Metric Guard registrano ciò che accade dopo.
Il confine architetturale spiega anche il modello di prodotto
Free mantiene un perimetro locale sostanziale; PRO introduce dati esterni, servizi remoti, code e automazioni che richiedono entitlement e governance aggiuntiva. Questo permette di spiegare la differenza senza ridurla a una semplice matrice di checkbox.
Free · continuity locale
SEO Essentials, TOC, Schema, linking core, Priority Sitemap, Sentinel e audit performance hanno una base operativa nel Client.
Local-first
PRO · remote intelligence
GSC/GA4 workflows, content automation, indexing orchestration e performance advanced aggiungono servizi e stato remoto.
Governed remote services
Un servizio esterno può fallire senza rendere indistinguibile lo stato del sito
Il sistema non può eliminare outage, rate limit o errori di provider. Può però mantenere confini che rendano chiaro quale funzione è degradata, quale stato locale rimane autorevole e dove usare retry, fallback o review.
Provider non disponibile
Le funzioni che dipendono dal provider possono degradare o fermarsi; i moduli locali non devono fingere un risultato remoto inesistente.
Dati Google in ritardo
Search Console e URL Inspection hanno tempi e semantiche proprie; monitoring e UI devono evitare di presentare dati remoti come istantanei.
Conflitto di scrittura
Quando un writer esterno osserva stato vecchio, compare-and-set può restituire conflitto invece di perdere una modifica concorrente.
Automazione performance regressiva
Metric Guard e copie reversibili, dove supportate, danno al workflow una via di recupero invece di trattare l’apply come finale.
Le relazioni sono parte dell’architettura, non solo della UI
Molti dei vantaggi operativi dipendono dal fatto che un modulo possa leggere decisioni o segnali già prodotti altrove senza duplicarne ownership e logica.
Sitemap / LLM / monitoring
Una decisione noindex può influenzare rappresentazioni e workflow che non devono trattare la URL come attiva.
Content / intelligence / monitoring
Le stesse fonti possono entrare in brief, decay, launch monitoring e priorità senza perdere provenienza.
WooCommerce / Knowledge Graph
Il modello reale collega catalogo, identificatori e Linked Data mantenendo separati listing e identità del prodotto.
Multi-module timeline
Eventi locali e remoti possono convivere in una cronologia che aiuta la diagnosi senza pretendere di provare causalità.
Domande sull’architettura
Le risposte distinguono continuità locale, dipendenze remote e ownership.
Free funziona se il Control non è disponibile?
La baseline prodotto descrive Free come local-first e sostanziale; le funzioni puramente locali possono continuare a vivere nel Client, mentre servizi remoti opzionali o workflow PRO restano dipendenze esterne.
PRO significa che tutto viene eseguito fuori da WordPress?
No. PRO aggiunge servizi, dati e orchestrazione remoti, ma l’applicazione e molte responsabilità restano nel Client WordPress e nei moduli proprietari.
Search Console e GA4 diventano un unico dataset interno?
Vengono riusati in più workflow, ma la loro semantica deve restare distinguibile: query/impression e engagement/key event rispondono a domande differenti.
Che cosa succede se un provider AI non risponde?
Il workflow che dipende da quel provider deve esplicitare il fallimento o il retry; non deve inventare un risultato. Le funzioni locali non collegate al provider rimangono separate.
Usa l’architettura per leggere correttamente le capability
Le pagine Funzionalità spiegano il comportamento dei moduli; Trust descrive i confini entro cui quei moduli operano. La matrice Compatibilità completa il quadro distinguendo architettura prevista da scenari realmente testati.