Non devi sapere come funziona un tag canonical prima di usare Hermes per migliorare una pagina. Ti servono un URL, l'accesso al progetto del sito quando sarai pronto a modificare i file e una regola chiara: Hermes controlla prima; tu approvi le modifiche dopo.
Questa guida mostra ai principianti come automatizzare il lavoro SEO ripetitivo con Hermes e la skill seo-auto-optimizer. Userai Hermes per ispezionare una pagina, farti spiegare i risultati in linguaggio semplice, preparare aggiornamenti approvati nei file del sito e testare il risultato prima della pubblicazione.
Automazione SEO non significa consegnare il sito a un agente e chiedergli di sistemare tutto. Significa lasciare all'agente le parti lente e ripetitive, mantenendo tu il controllo sulle decisioni che potrebbero rimuovere pagine dalla ricerca o confondere i visitatori.
Cosa avrai completato
Alla fine di questo primo flusso avrai:
- un URL importante controllato per problemi SEO visibili;
- un elenco breve e prioritario di modifiche con cui Hermes puo aiutarti;
- una spiegazione in linguaggio semplice di ogni raccomandazione;
- un insieme di modifiche revisionato nel progetto locale, se scegli di implementarlo; e
- una checklist di test prima del deployment.
Per il primo tentativo, prevedi da 30 a 60 minuti. Scegli una pagina importante per l'attivita: home page, pagina prodotto, pagina servizio o un articolo che riceve gia traffico. Non iniziare dall'intero sito.
Completato significa che sai indicare la pagina, spiegare cosa e cambiato e perche, e verificare che continui a funzionare. Non e una promessa di posizionamento: i motori di ricerca devono ricrawllare e valutare la pagina.
Prima di iniziare: quattro cose da preparare
Puoi iniziare senza Google Search Console e senza competenze tecniche. Il primo controllo usa segnali pubblici della pagina.
| Cosa serve | Perche serve | Se non ce l'hai ancora |
|---|---|---|
| Un URL pubblico | Hermes deve ispezionare una pagina precisa. | Parti dalla home o da una pagina servizio. |
| I file del progetto web | Hermes puo preparare modifiche approvate nei file sorgente effettivi. | Chiedi una copia o l'accesso al repository. Non modificare i file di produzione alla cieca. |
| Un'anteprima locale o staging | Devi vedere la pagina prima di pubblicarla. | Usa l'anteprima della piattaforma o chiedi un link di staging. |
| Un modo per fare deployment | Potrebbe essere Git, un CMS o un pannello hosting. | Per il primo tentativo mantieni manuale il deployment. |
Google Search Console, Bing Webmaster Tools e un export da crawler sono utili in seguito. Rispondono a domande che una sola pagina non puo risolvere, come cali di clic, URL in competizione o problemi di indicizzazione su larga scala.
Crea la skill SEO Auto Optimizer nel workspace Hermes
Devi creare tu il file della skill: non c'e alcun allegato da scaricare da questo articolo.
L'opzione piu rapida: invia questo articolo a Hermes
Quando questo articolo e pubblicato, puoi dare il suo URL a Hermes e chiedergli di installare la skill. Copia questo prompt, sostituisci [URL ARTICOLO] con l'URL live dell'articolo e invialo a Hermes:
Leggi questo articolo e installa la skill seo-auto-optimizer esattamente come indicato:
[URL ARTICOLO]
Sono un principiante. Trova il blocco completo di codice SKILL.md nell'articolo, crea il file skills/seo-auto-optimizer/SKILL.md nella directory skills corretta del workspace Hermes e copia il blocco esattamente nel file.
Prima di scrivere, dimmi il percorso completo. Dopo aver scritto, mostrami le prime 10 righe e conferma che il nome della skill e seo-auto-optimizer.
Non ispezionare il mio sito, non modificare file del sito, impostazioni o account, non fare deployment e non avviare ancora un audit SEO. Installa e verifica solo questa skill.
Se Hermes non puo aprire l'URL, segui il metodo manuale. Puoi anche incollare il blocco completo in chat dopo il prompt.
Nella cartella radice del workspace Hermes che userai per il SEO, crea:
tuo-workspace-hermes/
skills/
seo-auto-optimizer/
SKILL.md
Se Hermes usa una diversa directory skills configurata, crea la stessa struttura seo-auto-optimizer/SKILL.md li. Il nome della cartella e il valore name del file devono essere entrambi seo-auto-optimizer, cosi Hermes potra richiamarla con $seo-auto-optimizer.
Apri un file di testo semplice chiamato SKILL.md e incolla tutto il contenuto seguente. Non inserirlo nel codice del sito: appartiene alla cartella skills/seo-auto-optimizer/.
La skill parte in modalita di sola lettura. E intenzionale: controlla prove pubbliche e prepara un piano, ma non pubblica pagine, non invia sitemap, non modifica Search Console e non altera il sito live.
---
name: seo-auto-optimizer
description: Audit one public URL or a group of website URLs with evidence, then create an SEO optimization plan ranked by impact and effort. Use when a user asks to check, diagnose, optimize, or create an SEO task list, especially for indexing, technical SEO, metadata, structured data, content quality, internal links, search intent, keyword cannibalization, Core Web Vitals, mobile experience, CTR, Google Search Console, Bing Webmaster Tools, sitemaps, robots.txt, or E-E-A-T. By default, audit and provide code or copy recommendations only. Do not change the website, CMS, search-engine consoles, or third-party platforms.
---
# SEO Auto Optimizer
Turn a supplied URL into a verifiable SEO optimization plan that a developer, content team, or growth team can act on. Never present an item as checked or fixed when public evidence cannot confirm it.
## Working boundaries
- Default to read-only work. Inspect public pages, resources, and public site files. Do not change live pages, submit a sitemap, publish content, buy links, or operate any account.
- For a single-URL request, audit that URL and only the same-domain public files needed to verify it, such as `robots.txt`, a sitemap, or page links. Do not turn a single-page observation into a site-wide conclusion.
- Mark work that needs a login, search-performance data, a full crawl, server logs, or business facts as `Needs data`. State what data is needed and how to check it.
- Do not recommend black-hat, manipulative, or fabricated SEO: no purchased links, fake reviews/authors/comments, doorway pages, keyword stuffing, or bulk low-value AI pages.
- Follow the site's market, page language, URL conventions, and content standards. Proposed titles, meta descriptions, H1s, and body copy must use the target page's language.
## Inputs and clarification
A request needs at least one URL. If available, use the target market, language, business model, primary conversion, target keywords, Google Search Console or Bing exports, and local website project.
When those details are missing, do not block the work. Infer what you can from the page language, page type, and visible content, then state your assumptions at the beginning of the report. Ask one focused question only when the user requests keyword strategy, competitive content, or a site-wide change and the answer would materially depend on the target market or business.
## Audit process
### 1. Build an evidence baseline
1. Record the inspection date, final URL, HTTP status, redirect chain, `<html lang>`, visible robots instructions, and page-rendering limits.
2. Read the first screen, main content, and available source or DOM. Record the title, meta description, canonical, robots meta, viewport, H1-H6, visible publish or update date, author information, approximate body length, images, internal and external links, JSON-LD, and important JavaScript dependencies.
3. Check the same-domain `/robots.txt`. Check a sitemap only when one is discoverable; do not say a sitemap does not exist merely because its URL is not explicitly listed.
4. Keep locatable evidence for every conclusion: tag text, HTTP header, link URL, DOM observation, screenshot observation, or public-tool result. If the page is blocked by a WAF, login, geography, or another access limit, state the limitation immediately.
### 2. Classify every check
Use exactly one status for each item:
| Status | Meaning |
| --- | --- |
| `Pass` | Public evidence shows the item meets its purpose. |
| `Issue` | Public evidence shows an error, risk, or clear omission. |
| `Opportunity` | It may not be an error, but there is a reasonable opportunity to improve visibility, click-through rate, user experience, or conversion. |
| `Needs data` | Google Search Console, Bing, logs, a full crawl, field performance data, or keyword data is required. |
| `Not applicable` | The page type or business does not need this item; explain why. |
Do not turn `Needs data` into an `Issue` just to fill a checklist. Resolve the root causes that affect crawling, indexing, user experience, or the page's main intent before minor copy changes.
### 3. Create an action plan
Merge findings into non-duplicative tasks and rank them:
- `P0`: The page cannot be crawled or indexed; an incorrect canonical; accidental `noindex`; critical 4xx/5xx; site-wide robots blocking; severe mobile or rendering failure.
- `P1`: Main-page intent or content mismatch; duplicate or thin content; missing or conflicting title and H1; unacceptable structured data; missing key internal links; obvious performance bottleneck.
- `P2`: CTR improvements; images and alt text; FAQs; author and update information; content expansion; topic or comparison pages; local link and URL improvements.
- `P3`: Growth experiments, link earning, business profiles, and monitoring that require performance data or external coordination.
For every task, state the problem, evidence, recommended action, owner (developer, content, SEO, or growth), acceptance criteria, and risk or prerequisite. Give specific code or copy only when current information supports it. Where brand facts are missing, use clear placeholders instead of inventing facts.
## What to check
### A. Crawling, indexing, and URLs
Check and report:
- HTTP status, whether redirects are single-hop and appropriate, loops, and HTTP/HTTPS or www/non-www confusion.
- `robots.txt`, meta robots, `X-Robots-Tag`, and whether canonical URLs are reachable, absolute, single, self-referencing, or point to a sensible preferred URL.
- Whether canonical, `noindex`, pagination or filtering rules, and sitemap behavior agree. Mark uncertain cases as `Needs data`.
- Whether URLs are stable, readable, descriptive, free of meaningless parameters, case or trailing-slash duplication, and keyword stuffing. Do not recommend casual URL changes unless the plan includes 301 redirects, internal-link updates, canonical updates, sitemap updates, and rollback conditions.
- Whether main content appears in initial HTML or can render reliably. When important content depends only on client-side JavaScript, recommend verification with URL Inspection, rendering tests, and server-side rendering or prerendering options.
- Discoverable broken links, 404s, soft 404s, and incorrect internal destinations. A single URL cannot prove that a whole site has no broken links.
### B. Page structure and metadata
Check:
- A unique, accurate, intent-matched title. For Latin-script languages, a rough 50-60 characters can be useful, but accuracy matters more than reaching a count.
- A unique meta description that describes the page's real value without keyword lists or false promises. A meta description is not a ranking guarantee; prioritize relevance and likely click-through appeal.
- One H1 that describes the page's main question. Organize H2 and H3 headings by real topic hierarchy, without skipped levels or decorative text disguised as headings.
- `lang`, viewport, mobile usability, the ratio of main content to template noise, and breadcrumb visibility and semantics.
- Appropriate image formats, dimensions, lazy loading, and specific alt text. Decorative images should have empty alt text. Do not force keywords into alt text.
When recommending a rewrite, provide one adoptable title, meta description, H1, and heading outline. Label any information that needs a brand-owner confirmation.
### C. Structured data and trust signals
Check whether visible page content and JSON-LD, Microdata, or RDFa agree. Consider only schema appropriate to the page type: `BreadcrumbList`, `Article` or `BlogPosting`, `Product`, `SoftwareApplication`, `Organization`, `LocalBusiness`, `FAQPage`, and `WebPage`.
- Recommend schema only when it represents visible, real page information. Never add invented ratings, reviews, prices, authors, FAQs, or awards.
- Identify required fields such as URL, name, description, image, author, publish date, `dateModified`, breadcrumb positions, and entity identifiers.
- For content pages, check visible author information, author page or experience, editorial policy, sources, contact information, organization information, update date, and factual citations. E-E-A-T is not a tag that can be added; it comes from verifiable content and entity information.
- When schema exists, recommend the Google Rich Results Test and Schema Markup Validator as acceptance checks.
### D. Content, intent, and duplication
Identify the page's main query intent: informational, commercial research, transactional, local, navigational, or mixed. Check whether the main content answers the question early and adds value through original evidence, examples, steps, data, or product detail.
- Flag clear thin content, template repetition, unanswered core questions, intent mismatch, and stale content. Do not define thin content by word count alone.
- A single URL cannot prove site-wide duplicate content, keyword cannibalization, or orphan pages. Explain that these require a URL inventory, canonical and index status, GSC query-to-page data, an internal-link graph, and similarity analysis.
- For overlapping pages, first define the evidence and decision criteria for keep, merge, split, or redirect. Never recommend deleting a page based on a guess.
- When content creation is requested, provide a search-intent brief, unique value, information architecture, sources needed for claims, and internal-link targets. Original content means independent insight or verification, not a competitor rewrite.
- Suggest comparison, alternatives, list, or FAQ pages only when they have distinct intent, real comparison criteria, and maintainable facts. Do not create batches of low-value templates.
### E. Internal links, architecture, and topic coverage
Assess how the page can be found and understood:
- Check whether important pages have crawlable HTML links from relevant parent pages, topic hubs, navigation, or breadcrumbs. Anchor text should naturally describe the destination.
- Mark orphan pages as `Needs data` unless a sitemap and full link graph prove the finding.
- For a topic cluster, define one pillar or owner URL, a distinct intent for each support page, link direction, and a cannibalization rule. Multiple near-identical owner pages should not compete for one head topic.
- Before suggesting feature, use-case, integration, comparison, alternatives, or FAQ pages, define the user question, target query, unique content, owner URL, and link-back path.
### F. Performance, mobile use, and Core Web Vitals
Separate lab data from field data. Prefer real-user data from CrUX or PageSpeed Insights to validate LCP, INP, and CLS. Without it, inspect obvious risks: oversized hero media, images without dimensions, render-blocking CSS or JavaScript, third-party scripts, font loading, layout shifts, and heavy client-side rendering.
Every performance recommendation must explain its mechanism and test method. For example: responsive, compressed hero media may improve LCP; image width and height reduce CLS risk; splitting long tasks may improve INP. Do not promise a score or ranking improvement.
### G. Search performance, keywords, and external authority
Unless the user supplies data or access, mark these items as `Needs data`:
- Page-two rankings, traffic or ranking declines, and query-to-page keyword cannibalization.
- URLs or queries with high impressions and low CTR, plus title and meta tests.
- High-volume, low-difficulty keywords, SERP and People Also Ask opportunities, competitor gaps, and search intent.
- High-quality backlinks, broken-link opportunities, brand mentions, Google Business Profile, and local citations.
- GSC or Bing sitemap submission, URL Inspection, index coverage, and crawl errors.
Give an executable data-checking instruction. For example: in GSC, compare the last 28 days with the previous 28 days, filter to the target URL, export queries, impressions, clicks, CTR, and average position, then test a new title or meta description for high-impression, same-intent queries with weak CTR. Link strategies must use audience-relevant, editorially independent, verifiable channels and genuinely useful assets.
## Default deliverable format
Unless the user asks for a shorter response, return these sections in this order:
1. `Scope and limits`: target URL, check date, accessibility, what could not be verified, and key assumptions.
2. `Executive summary`: the three to seven most important findings and what to address first.
3. `Check matrix`: status, evidence, and short conclusion for items A-G. Cover the user's supplied checklist, and state `Needs data` where necessary.
4. `Prioritized action list`: P0-P3 tasks with owner, effort (S/M/L), acceptance criteria, and dependencies.
5. `Implementation-ready recommendations`: where appropriate, include metadata, heading structure, JSON-LD templates, internal-link locations, content briefs, or performance fixes.
6. `Data and human follow-up`: needed GSC, Bing, crawl, log, keyword, and business inputs, plus exact validation steps.
Use careful language. Say a change may improve relevance, discoverability, or CTR. Do not promise indexing, first place rankings, or that every SEO issue has been fixed.
## Completion standard
Before delivering the work, confirm:
- Every conclusion has public evidence or is explicitly labeled as an assumption or `Needs data`.
- Tasks are ordered by impact, dependency, and actual executability, not copied mechanically from a checklist.
- Recommendations do not risk breaking URLs, canonicals, index status, or content facts. Migration, deletion, and merge suggestions include redirect and rollback conditions.
- Schema and E-E-A-T recommendations come from visible facts or are clearly marked as information still needed.
- The report makes clear that no live changes, submissions, or publishing actions were performed.
Salva il file. Riavvia o ricarica Hermes se necessario, quindi chiedi: Elenca le skill disponibili in questo workspace. seo-auto-optimizer e disponibile? Non iniziare il tutorial finche Hermes non lo conferma.
Controlla una pagina prima di chiedere a Hermes di modificare qualcosa
Apri Hermes e incolla questo prompt, sostituendo l'URL di esempio.
Usa $seo-auto-optimizer per ispezionare questa pagina:
https://example.com/your-page
Sono nuovo nella SEO. Spiega ogni risultato in linguaggio semplice.
Non modificare file, non pubblicare pagine, non inviare nulla e non fare modifiche al sito live.
Per ogni raccomandazione mostra:
1. Cosa ha trovato Hermes e dove.
2. Perche puo contare per visitatori o motori di ricerca.
3. Se e un problema confermato, un'opportunita o richiede altri dati.
4. L'azione successiva piu sicura.
5. Se servono uno sviluppatore o dati di Google Search Console.
Ordina il lavoro per priorita: P0, P1, P2, poi P3.
Il primo risultato deve essere un rapporto, non un sito modificato. E corretto. Hermes puo in genere controllare title, meta description, heading principale, alt text, link interni, canonical, istruzioni robots, dati strutturati, viewport mobile e link palesemente rotti. Puo anche individuare lacune di contenuto a livello di pagina.
Non deve fingere di sapere tutto: un rapporto che dice Needs data e spesso piu affidabile di uno che diagnostica l'intero sito da un solo URL.
Leggi il rapporto senza diventare esperto SEO
La skill usa due etichette semplici: stato e priorita.
| Etichetta | Significato | Risposta adatta a un principiante |
|---|---|---|
|
| Le prove pubbliche suggeriscono che questo punto va bene. | Lascialo stare. |
|
| Hermes ha trovato un problema concreto, come un H1 mancante o un link errato. | Controlla la prova e valuta una correzione. |
|
| La pagina non e rotta ma puo essere piu chiara o utile. | Considerala un miglioramento facoltativo. |
|
| Servono GSC, Bing, analytics, log o un crawl completo. | Non indovinare: raccogli i dati in seguito. |
| Priorita | Significato semplice | Esempi |
|---|---|---|
|
| Un problema grave puo impedire a una pagina importante di comparire o funzionare. |
|
|
| Struttura, intento o configurazione tecnica hanno una debolezza significativa. | Title/H1 mancanti o in conflitto, intento errato, schema non valido, link interni importanti assenti. |
|
| Miglioramento utile, ma non urgente. | Alt text migliore, FAQ chiare, informazioni su autore o aggiornamento, test di title e description. |
|
| Lavoro che richiede dati, un altro team o un esperimento continuo. | Link earning, profili locali, monitoraggio ranking o ricerca keyword. |
Non approvare tutto perche appare nel rapporto. La prima implementazione dovrebbe contenere da una a tre modifiche a basso rischio: una piccola release e piu facile da controllare e annullare.
Scegli le prime modifiche sicure e rimanda le decisioni rischiose
| Di solito sicuro da preparare e rivedere | Fermati e chiedi una revisione tecnica o SEO |
|---|---|
| Title o meta description piu accurati | Cambiare URL o eliminare pagine |
| Un H1 chiaro e H2 sensati | Modificare |
| Alt text specifico per immagini significative | Regole di redirect o impostazioni di migrazione |
| Un link interno rotto con destinazione evidente | Unire pagine solo perche sembrano simili |
| Schema che rifletta contenuto visibile e verificato | Aggiungere valutazioni, recensioni, prezzi, autori o FAQ non reali |
| Una breve risposta che chiarisca una pagina esistente | Pubblicare molte pagine AI per keyword |
Un canonical indica ai motori quale versione di pagine simili considerare principale. Modificarlo puo essere importante, ma puo anche chiedere a Google di ignorare la pagina che ti interessa. Chiedi a Hermes di mostrare URL canonical corrente e proposto, quindi ottieni una revisione tecnica. Lo stesso vale per robots.txt e noindex, che possono essere corretti per pagine di ringraziamento, anteprime private o risultati filtrati.
Chiedi un piano di implementazione, non una modifica a sorpresa
Approvo solo queste modifiche SEO:
[INCOLLA GLI ELEMENTI APPROVATI]
Esamina il mio progetto web locale e prepara un piano di implementazione. Prima di modificare un file, mostra tutti i file previsti, la pagina o componente interessato, cosa cambiera per utenti e motori, come testeremo il risultato e come annullare la modifica se fosse errata.
Non cambiare URL, non eliminare pagine, non modificare robots.txt, non aggiungere noindex, non cambiare redirect, non pubblicare contenuti, non fare deployment e non fare modifiche fuori dall'elenco approvato.
Attendi la mia approvazione dopo aver mostrato il piano.
Controlla l'elenco dei file. Se Hermes vuole toccare file sconosciuti, chiedi perche. Se il piano dice solo "ottimizza SEO" senza nominare file e risultato atteso, chiedi maggiore precisione.
Quando il piano va bene, dai un'approvazione ristretta:
Approvato. Implementa solo il piano sopra.
Dopo le modifiche: dammi un riepilogo per file, mostra il diff o il prima/dopo rilevante, spiega cio che devo verificare manualmente, esegui i controlli disponibili del progetto e non fare deployment.
Hermes puo svolgere modifiche ripetitive, ma tu decidi cosa cambia e quando pubblicare.
Controlla il risultato prima che la pagina vada online
Non saltare l'anteprima: una modifica valida tecnicamente puo sembrare strana, rompere il layout o rendere la pagina meno utile.
| Controllo | Cosa cercare |
|---|---|
| Anteprima browser | La pagina carica e il testo modificato suona naturale. |
| Anteprima mobile | Heading, immagini, menu e pulsanti funzionano su schermo stretto. |
| Title e description | Descrivono la pagina reale senza promettere cio che non offre. |
| Struttura heading | Un H1 chiaro descrive la pagina e gli H2 organizzano sezioni reali. |
| Link | I link interni modificati portano alla pagina live o staging prevista. |
| Immagini | Le immagini importanti hanno alt text utile; quelle decorative non hanno alt text pieno di keyword. |
| Sorgente o estensione SEO | Canonical, robots e dati strutturati attesi non sono cambiati inaspettatamente. |
| Controlli progetto | Build, test, lint o validazioni esistenti passano. |
Per modifiche allo schema, esegui Google Rich Results Test o Schema Markup Validator dopo il deployment, o su staging raggiungibile. Uno schema formalmente valido deve anche corrispondere a cio che gli utenti vedono.
Se un controllo fallisce, non chiedere modifiche casuali. Fornisci l'errore esatto, indica la modifica approvata che l'ha causato e chiedi la riparazione minima. Se non sai spiegare o validare una modifica, annullala prima del deployment.
Cosa l'automazione SEO non puo sapere da una pagina
| Domanda | Cosa serve a Hermes per rispondere responsabilmente |
|---|---|
| Perche il traffico e calato? | Dati GSC e analytics di due periodi confrontabili. |
| Quali pagine hanno molte impression ma CTR basso? | Export di query e pagine da GSC. |
| Due pagine competono per la stessa keyword? | Dati query-pagina GSC e confronto dei contenuti. |
| Quali pagine sono orfane? | Crawl completo, sitemap e grafo dei link interni. |
| Core Web Vitals falliscono davvero per gli utenti? | Dati reali come CrUX o PageSpeed Insights, non solo test locale. |
| Quali keyword a bassa difficolta scegliere? | Ricerca keyword e SERP, piu conoscenza di pubblico e offerta. |
| Inviare una sitemap o richiedere indicizzazione? | Accesso a GSC o Bing Webmaster Tools e una ragione concreta. |
Potrai automatizzare la raccolta e l'organizzazione di questi dati in seguito. Per la prima pagina e sufficiente che Hermes segni Needs data, invece di trasformare una supposizione in diagnosi.
Una semplice routine settimanale
Quando la prima pagina e online e verificata, ripeti il flusso ogni settimana su una pagina importante:
- Scegli una pagina con uno scopo commerciale, non un URL casuale.
- Esegui il controllo Hermes in sola lettura.
- Approva solo pochi aggiornamenti chiari e a basso rischio.
- Rivedi il piano di implementazione e il diff dei file.
- Testa in locale o staging prima del deployment.
- Registra pagina, data, modifiche e domande aperte in un foglio di calcolo o file Markdown.
Dopo alcune settimane aggiungi export GSC. Hermes potra aiutarti a trovare pagine il cui prossimo miglioramento sia supportato da impression, clic o query reali. Per una diagnosi piu ampia usa anche il controllo del punteggio SEO del sito insieme alla revisione a livello di codice.
FAQ
Hermes puo automatizzare tutta la SEO del mio sito?
No. Hermes puo automatizzare lavori ripetibili: revisione di segnali pubblici, elenco dei problemi, bozze di title e description, preparazione di modifiche al codice o ai contenuti e controllo di un elenco approvato. Decisioni su eliminazione pagine, redirect, controlli di indicizzazione, canonical, affermazioni commerciali, deployment o dati di performance richiedono ancora revisione umana.
Devo conoscere le keyword SEO prima di iniziare?
No. Inizia da una pagina importante e chiedi a Hermes di spiegare la sua configurazione SEO visibile. La ricerca keyword serve quando vuoi creare nuove pagine o decidere quali esistenti meritano lavoro: richiede dati e comprensione dei clienti, non solo una lista generata da un agente.
Hermes puo modificare una pagina WordPress, Webflow o Shopify?
Solo se l'ambiente Hermes ha accesso autorizzato al sistema o ai file del sito. Per il primo flusso chiedi a Hermes di preparare testo, codice o modifica a livello di file; poi fai tu l'aggiornamento CMS o chiedi approvazione al proprietario. Non concedere accesso di pubblicazione prima di avere un processo di revisione affidabile.
Queste modifiche faranno arrivare la mia pagina prima su Google?
No. Le modifiche SEO possono migliorare crawlability, pertinenza, chiarezza ed esperienza utente. I ranking dipendono anche da concorrenza, intento di ricerca, qualita del sito, link e valutazione dei motori nel tempo. Considera Hermes uno strumento per decisioni migliori e piu sicure, non una garanzia di ranking.
Autore: Julian Mercer, professionista di SEO tecnica da 14 anni presso Auspia. Julian scrive di crawlability, schema, rendering, architettura del sito e basi tecniche per contenuti leggibili dall'AI.
