www, apex e wildcard forwarding senza rompere il SEO
La normalizzazione dell’host sembra semplice finché root domain, www, subdomain, path e query string seguono regole diverse. Una policy chiara mantiene stabile la URL canonica.
La normalizzazione dell’host sembra un compito piccolo, finché non arriva traffico vero.
Il brand preferisce il dominio apex. Il sito vecchio usa www. Un prodotto, una documentazione o una landing vive su un subdomain. L’agenzia chiede wildcard forwarding. Una campagna ha ancora bisogno di preservare path e UTM. Se queste decisioni vengono prese separatamente, il risultato di solito è una redirect chain.
La domanda non è se www o apex siano sempre migliori. La domanda è quale host sarà canonico e come tutte le altre varianti lo seguiranno.
Se questo fa parte di una migrazione più ampia, inizia dalla checklist di redirect per migrazione sito. Qui il focus è solo sul livello host.
L’host fa parte della policy URL
example.it, www.example.it e *.example.it non sono uguali sul piano operativo.
- L’apex può essere più pulito in marketing.
wwwè ancora comune in stack più vecchi.- Un subdomain può essere un prodotto, docs, support o shop.
- Il wildcard forwarding aiuta quando molti host devono seguire la stessa regola.
Quello che conta è non lasciare la scelta al caso.
Scegli l’host canonico prima del go-live
Rispondi presto a queste domande:
| Domanda | Perché conta |
|---|---|
Il sito vive su apex o www? | Definisce la URL canonica visibile |
| Quali subdomain sono alias? | Non tutti devono essere unificati |
| I path devono sopravvivere? | SEO, bookmark e deep link dipendono da questo |
| Le query string devono restare? | UTM, coupon e ID possono sparire |
| Esistono eccezioni temporanee? | Campagne e launch possono richiedere logica diversa |
Se lasci queste risposte aperte, più layer proveranno ad aiutare insieme.
Il DNS non risolve tutto
Il DNS indica dove va il traffico. Non decide da solo il cambio visibile di URL.
Modello pulito:
http://www.vecchio-brand.example/prezzi?utm_source=newsletter
-> https://nuovo-brand.example/prezzi?utm_source=newsletterModello fragile:
http://www.vecchio-brand.example/prezzi
-> https://www.vecchio-brand.example/prezzi
-> https://vecchio-brand.example/prezzi
-> https://nuovo-brand.example/prezziUn solo hop è più facile da auditare e mantenere.
Il wildcard forwarding funziona se la struttura resta allineata
Una regola wildcard aiuta quando i path restano compatibili:
old.example.it/* -> new.example.it/$1Funziona bene quando:
- ci sono molte URL vecchie da preservare
- la struttura non è cambiata troppo
- non vuoi scrivere una regola per ogni pagina
- i vecchi subdomain sono veri alias
Se l’architettura cambia molto, mappa esplicitamente le URL importanti.
Conserva path e query quando il link conta ancora
La normalizzazione dell’host non deve cancellare il contesto.
http://old.example.it/docs/api?ref=partner&utm_source=newsletterdovrebbe finire, se la struttura lo consente, in:
https://new.example.it/docs/api?ref=partner&utm_source=newsletterQuesto è importante per:
- pagine SEO
- documentazione
- paid campaign
- affiliate link
- link salvati dagli utenti
Se path o query spariscono, il redirect sembra corretto e perde comunque valore.
Evita la chain
L’errore più comune è distribuire le responsabilità:
- HTTP verso HTTPS da una parte
wwwverso apex da un’altra- cambio dominio in CDN o hosting
- l’app aggiunge un’altra canonical rule
Il risultato diventa http -> https -> www -> final.
Se la tua stack ha già questa forma, guarda Redirect chains and loops.
Testa una matrice di lancio
Prima di pubblicare, prova le varianti reali:
| Test | Esempio |
|---|---|
| Apex root | https://example.it/ |
www root | https://www.example.it/ |
| Deep path | https://example.it/prezzi |
| Deep path con query | https://example.it/prezzi?utm_source=email |
| Vecchio host con path | https://old.example.it/blog/post-1 |
| Subdomain wildcard | https://docs.example.it/guide |
Controlla:
- host finale corretto
- path preservato
- query preservata
- status code giusto
- nessun hop extra
Dove entra UrlEdge
UrlEdge è utile quando la normalizzazione dell’host deve diventare una policy di routing, non uno snippet sparso.
- Free Redirect Service per HTTPS automatico e wildcard forwarding
- Advanced Redirect Rules per logica condizionale
- Redirect Checker per ispezionare gli hop reali
- Redirect domain senza perdere path e query per il pattern completo
Il vantaggio è avere un solo posto responsabile per host canonico, varianti, path, query e status code.
FAQ
Devo sempre preferire apex a www?
No. Entrambi funzionano. L’importante è scegliere un canone e far seguire le varianti in modo pulito.
Posso coprire i wildcard subdomain con una sola regola?
Sì, se la struttura resta allineata. Se è cambiata molto, mappa esplicitamente le URL importanti.
Il DNS basta?
No. Il DNS non sostituisce una policy HTTP di redirect visibile all’utente.
Devo preservare i parametri di campagna?
Di solito sì, salvo motivo esplicito per rimuoverli. L’attribuzione persa è difficile da recuperare.
Riferimenti
Fissa una volta l’host canonico
Reindirizza root, www e wildcard subdomain con HTTPS automatico, conservazione del path e una destinazione canonica.
Prova Free Redirect ServiceArticoli correlati
Visualizza tutto
Link firewall per traffico paid e affiliate: filtra bot, proxy e clic sospetti
Non ogni clic sospetto è frode, ma ogni clic sospetto può far saltare budget, attribuzione e report partner. Un link firewall decide cosa succede prima che il traffico arrivi alla destinazione.
Servire i file di verifica all’edge: ads.txt, security.txt, AASA e assetlinks.json
Alcuni file devono vivere nella root o sotto /.well-known/. Se CMS o store rendono la cosa scomoda, una risposta edge può servirli con status e Content-Type corretti.