Skip to main content
Glama

analizza_seo_sito

Samples a site’s home, sitemap, categories, and products to report SEO structure and product-description language for competitive research.

Instructions

Analizza a campione il sito di un altro negozio (di norma un concorrente) per capire come e' fatta la sua SEO e come descrive i prodotti: scarica la home, la sitemap, qualche categoria e una decina di prodotti (dura qualche decina di secondi: rispetta robots.txt e fa pause fra le richieste).

Il report contiene, oltre ai campi SEO (titoli, meta description, H1/H2, dati strutturati, ALT), il TESTO analizzato: vocabolario (parole e coppie di parole ricorrenti, unita' di misura), segnali di stile e intenzione ogni 1000 parole (inviti all'acquisto, fiducia e servizio, offerte, confronto e guida, tono "tu" o "noi", tecnicismo, lunghezza delle frasi), struttura delle descrizioni (paragrafi, elenchi, tabelle, video), i messaggi che il sito ripete ovunque (spedizione, resi, inviti) e, per ogni pagina, un breve estratto della descrizione. Non esegue JavaScript: se il sito costruisce le pagine cosi' o serve pagine segnaposto, lo dice negli avvisi. Rifiuta indirizzi di reti private.

url puo' essere l'indirizzo del sito o di una sua SEZIONE (es. https://www.euronics.it/telefonia/): in quel caso sitemap e link restano dentro quella sezione e il report indica il perimetro. Utile per i grandi cataloghi. Se punta a una PAGINA di categoria (es. .../smartphone-1001.html) il campione si sceglie fra le sottocategorie e i prodotti che quella pagina elenca, senza usare la sitemap.

COME USARLO: dal report ricava tu l'intenzione (informativa, comparativa, d'acquisto), il tono, cosa il sito enfatizza e come struttura le descrizioni, quali termini e misure usa per la categoria. Poi scrivi testi ORIGINALI per i nostri prodotti, con parole tue: gli estratti servono ad analizzare, non a riusare. Mai copiare frasi, titoli o description del concorrente, e solo cose vere sui nostri prodotti. Prima di applicare i testi con i tool SEO (aggiorna_seo_prodotto, crea_prodotto) passali a controlla_somiglianza, fai scegliere all'utente il livello di somiglianza che accetta e mostragli l'anteprima.

Il riepilogo dei punteggi (senza i testi delle pagine) viene mandato anche al plugin, che lo mostra nella tab SEO di wp-admin; plugin nel report dice se e' stato salvato. Se l'indirizzo e' quello del sito dell'utente, e' segnato come "Il tuo sito".

caratteri_per_pagina e' la lunghezza dell'estratto di ogni pagina (0 = nessun estratto, massimo 2000): e' quello che pesa sui token del report. max_categorie e max_prodotti alzano il campione fino a un tetto (10 e 30). I testi analizzati restano salvati in locale per controlla_somiglianza.

Il report ha una valutazione della struttura SEO del sito da 0 a 9, per area (titoli, meta description, intestazioni, dati strutturati, contenuto, aspetti tecnici) e complessiva, con la prova di ogni criterio: dice se il sito e' un buon modello. E' SOLO UN RIFERIMENTO: un sito scadente puo' essere buono su un'area. Prima di proporre testi ispirati al sito, mostra all'utente punteggio e aree e chiedigli se vuole usarlo come ispirazione e per quali aree; non decidere tu.

usa_curl: fa le richieste con il programma curl invece che con la libreria Python (stesso User-Agent dichiarato, stesso rispetto di robots.txt, pause e Retry-After: se il sito risponde ancora 429 si ferma). Usalo SOLO se l'utente lo chiede esplicitamente, tipicamente per un sito che risponde 429 alla libreria ma non a curl: e' una sua scelta e una sua responsabilita'. Non cambiare User-Agent e non aggirare altri blocchi.

usa_browser: attiva il metodo con un browser vero (Chromium in locale, con il suo User-Agent di serie, senza scaricare immagini e video). Funziona anche per i siti costruiti con JavaScript. L'utente puo' attivarlo una volta per tutte con SEO_ANALISI_USA_BROWSER=1; imposta questo parametro solo se l'utente lo chiede. Con il browser attivo la scala e': HTTP; se la home risponde 403/429 o sembra costruita con JavaScript, si aspetta il Retry-After e si passa al browser. Il report dice il metodo usato. Se nemmeno il browser basta, l'errore suggerisce analizza_pagine_salvate.

browser_visibile: come usa_browser ma con la finestra del browser visibile sullo schermo dell'utente (SEO_ANALISI_BROWSER_VISIBILE=1 per averlo sempre). Alcuni siti rifiutano il browser senza finestra e non quello visibile. Usalo solo se l'utente lo chiede o lo approva dopo un rifiuto (403/429) anche con usa_browser: e' un tentativo in piu' contro un rifiuto del sito, non il metodo predefinito.

Input Schema

NameRequiredDescriptionDefault
urlYes
usa_curlNo
usa_browserNo
max_prodottiNo
max_categorieNo
browser_visibileNo
caratteri_per_paginaNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose a lot: robots.txt compliance, pauses, Retry-After, duration (tens of seconds), no JavaScript unless browser mode, private-network rejection, local storage of analyzed texts, and that a summary is sent to the plugin. However, the numerous behavior and performance details are buried across a very long paragraph rather than front-loaded, and the report's exact shape is only partially conveyed, so the signal is strong but dense.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded (purpose, then report contents, then COME USARLO, then per-parameter notes) which suits a 7-parameter tool with complex behavior. Still, it is very long and some sentences overlap (usa_browser and browser_visibile repeat environment-variable and 403/429 logic), costing a little efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description supplies what an agent needs: report contents (SEO fields, vocabulary, style/intent signals per 1000 words, structure, repeated messages, estratto), the valutazione 0-9 scale, the 'Il tuo sito' marker, plugin persistence, and all fallback paths. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it largely does: url can be a site, a section (perimetro), or a category page with different sampling behavior; caratteri_per_pagina (0 = none, max 2000, affects token cost); max_categorie/max_prodotti raise the sample to a cap (10 and 30); usa_curl, usa_browser, browser_visibile each have explicit conditions. The cap phrasing '(10 e 30)' is slightly ambiguous about which limit maps to which parameter, and defaults are not stated, keeping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (analizza a campione) and a specific resource (il sito di un altro negozio, di norma un concorrente), with the exact scope of what gets fetched: home, sitemap, categories, ~10 products. It is clearly distinguishable from siblings like analizza_pagine_salvate (named as a fallback) and controlla_somiglianza (named as the downstream step).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: when to use curl (only if the user asks, 429 fallback), when to use browser/visible browser (only on request or after a 403/429 refusal), and the fallback to analizza_pagine_salvate if the browser still fails. It also dictates the downstream workflow (pass texts to controlla_somiglianza, ask the user for the acceptable similarity level, show a preview) and warns against copying competitor text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.