Il documento fornisce una guida su come gestire siti web utilizzando WebSphere Portal e WCM, concentrandosi sull'ottimizzazione SEO e sull'esperienza utente. Vengono discussi suggerimenti per migliorare i ranking nei motori di ricerca, l'importanza della normalizzazione degli URL e la creazione di pagine di cortesia efficaci. Inoltre, viene descritto come configurare il server HTTP per migliorare la visibilità dei contenuti e gestire errori tramite pagine personalizzate.

1. WebSphere Portal e WCM
gestire siti web aderendo alle linee
guida SEO per migliorare il ranking
dei siti, e l'user experience
Andrea Fontana
Mail: andrea.fontana@factor-y.com

2. Mi presento:
Andrea Fontana:
• Ho cominciato a lavoro in ambiente “Lotus” dal '92
(notes 2.8), prima come Amministratore poi come
sviluppatore
• Mi sono occupato di ottimizzazioni SQL sia su DB2 che
Digital RDBMS come DBA
• Dal 2001 lavoro in ambito WebSphere Portal (3.5) e
soluzioni Collaborative
• Attualmente lavoro in Factor-y
•

3. Focus
• SEO
– Quali suggerimenti considerare
• Pagine di cortesia
– Come gestisco pagine di cortesia diverse
mantenendo il look & fell in soluzioni Mutli-
Brand?

4. SEO
(Search Engine Optimization)

5. Search Engine Optimization è un soggetto
Complesso
I punti focali su cui operare tipicamente sono:
• <meta Title
• <meta Description
• Researchable KeyWord , hanno senso??
– Keyword stuffing.....
• Link ref “Canonical”
• Improve the structure of your URLs
• Use pages courtesy
• …..

6. Guideline to Seo
Riepilogando i punti su cui lavorare sono:
• Utilizzare delle parole sensate nell’URL
• Semplifica la struttura delle tue rotte
• Fornire una versione unica dell’URL per
raggiungere una data risorsa
• Usare pagine di cortesia che siano utili

7. Normalizzazione URL
Step 1: Risposta in “/”
Obbiettivo: fare in modo che il sito sviluppato con WebSphere Content Manager risponda ad una URL del tipo
http://<fqdn> invece dell'url standard del tipo
http://<fqdn>/wps/wcm/connect/[LIBRARY]/[SITE]/[SITE AREA 1]/[SITE AREA 1.1]/[SITE AREA 1.1.1]/
[NAME+OF+CONTENT]/
Ad esempio:
http://www.agenziadogane.it/wps/wcm/connect/Internet/ed/
Ai fini del SEO sarebbe auspicabile che il sito rispondesse in
http://www.agenziadogane.it/

8. Risposta in /
Come farlo?
Usiamo l'http server di front-end.
Possiamo farlo in modo coerente al Seo o peggiorando la situazione, vediamo
come.
Se la redirect è gestita da una pagina html che esegue la redirect con un meta
tag del tipo
<meta http-equiv="Refresh" content="0;url=/wps/wcm....." />,
otteniamo che in 0 secondi verremo rediretti sul sito ma con quali risultati?
302 Moved Temporarily
Risultato lato crawler?
302 : indicizzo la pagina perchè la redirezione è temporanea
e indicizzo la nuova pagina perchè temporaneamente ci devo arrivare =
2 URL per il medesimo contenuto

9. Risposta in /
Alternativa ?
Usiamo le regole di rewrite di Apache / IHS
RewriteCond %{HTTP_HOST} ^<nome.host.fqdn>
RewriteCond %{REQUEST_URI} ^(/)?$
RewriteRule ^(/)?$ /wps/wcm/....../ [PT,NC]
200 OK!
Risultato lato crawler?
200 : indicizzo la pagina perchè la pagina in cui devo arrivare =
1 url , 1 contenuto

10. Risposta in /
Attenzioni da seguire nello sviluppo del sito con il WCM
• Tutti i riferimenti alla HomePage devono essere relativi e
puntare a “/”
Capiamo il perchè:
Analizzando la composizione di un URL si identificano le seguenti parti
Un link contenuto nella pagina composto con /path/contenuto, verrà ricomposto dal browser come
<schema><fqdn>/path/contenuto.
In questo modo nel nostro caso rientriamo nel ciclo della rewrite che ci permette di rispondere in /
evitando di far trovare per il medesimo contenuto sia l'URL / che l'url nativo nel formato
“/wps/wcm/connect/[LIBRARY]/[SITE]/[SITE AREA 1]/[SITE AREA 1.1]/[SITE AREA 1.1.1]/
[NAME+OF+CONTENT]/” evitando di ricadere nel fatto che il crwaler vede 2 indirizzi per lo stesso
contenuto.

11. Page Rank
Ovvero: l'importanza che l'intelligenza collettiva
del web da a una determinata pagina internet.
La differenza fondamentale tra i due metodi
di reindirizzamento è:
Caso <meta → 2 indirizzi → 1 contenuto proveniente dal medesimo FQDN
Caso rewrite → 1 indirizzo → 1 contenuto
I sistemi di crawling nel primo caso escludono il ranking generato dal secondo indirizzo.
100 50

12. Step2: Normalizzare ovvero eliminare le parti superflue
Ipotizziamo un sito ricco, molto ricco di contenuti,
ha senso che tutti i contenuti abbiano una radice
costante e ripetitiva?
Come abbiamo visto l'url di un sito sviluppato con il WCM è del tipo
http://<fqdn>/wps/wcm/connect/[LIBRARY]/[SITE]/......
Quale valore aggiunto può dare ai fini della ricercabilità la presenza per ogni contenuto della
parte costante? Identificata dal percorso
/wps/wcm/connect/[LIBRARY]/[SITE]/
Ripetuto per ogni contenuto?
Possiamo dire NESSUNO ! Quindi possiamo eliminarlo.

13. Step2: Normalizzare ovvero eliminare le parti superflue
Evitiamo URL fantasiose del tipo:
http://<fqdn>/wps/wcm/connect/libreria del sito 1/sito 1/contenuti multi mediali
Che il browser tradurra in
http://<fqdn>/wps/wcm/connect/libreria%20del%20sito%201/sito%201/contenuti%20multi
%20mediali
Se proprio dovete sostituite il ␢ (blank) con -
/libreria-del-sito-1........
Ma come si fa ad eliminare la parte costante?
Ci aiuterà ancora una volta l'HTTP Server (IHS o Apache)
Questo un buon motivo per usare l'Http server nativo l'IBM Http Server [ndr]

14. Step2: Normalizzare ovvero eliminare le parti superflue
L'Http server ci permette di convertire dinamicamente il contenuto delle pagine
web. Possiamo forzare il cambiamento da /wps/wcm/connect/libreria/site
sostituendolo run time con un percorso più semplice ad es, /newpath
Limitazioni conosciute:
• Non può cambiare i contenuti delle applet
• Non può cambiare i contenuti dei javascript embedded
• Non può cambiare i link assoluti

15. Step2: Normalizzare ovvero eliminare le parti superflue
La funzione sfrutta alcune librerie Apache, e la funzionalità di
R-Proxy. Schematicamente il flusso è il seguente:
Noi interverremo proprio nella configurazione del R-Proxy inserendo le funzioni
di “Proxy HTML” e lo schema diventa

16. Step2: Normalizzare ovvero eliminare le parti superflue

17. Step2: Normalizzare ovvero eliminare le parti superflue
Come fare:
Installare e caricare le librerie necessarie:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
Abilitare i Virtual Host
Sia per il sito principale in cui inseriremo le regole di “riscrittura”
Sia per il sito Privato “riscrivente”

18. Step2: Normalizzare ovvero eliminare le parti superflue
VH sito principale:
Inserie le regole di proxy-HTML
Sostituiremo la rotta /wps/wcm/connect/mysite/site/ con /it/
ProxyHTMLLogVerbose On
LogLevel Debug
ProxyPass /it/ http://www1.mysite.com/wps/wcm/connect/mysite/site/
ProxyHTMLURLMap http://www1.mysite.com/wps/wcm/connect/mysite/site/ /it [c]
<Location /it/>
ProxyHTMLEnable On
ProxyPassReverse http://www1.mysite.com/wps/wcm/connect/mysite/site/
SetOutputFilter proxy-html
ProxyHTMLURLMap /wps/wcm/connect/mysite/site/ /it/
ProxyHTMLURLMap /it /it
</Location>

19. Step2: Normalizzare ovvero eliminare le parti superflue
VH “privato”:
<VirtualHost <yourIP>:80>
DocumentRoot www/mysite
ServerName www-1.mysite.com
ErrorLog logs/www/mysite/error.log
CustomLog logs/www/mysite/access.log common
</VirtualHost>
In questa configurazione l'fqdn www.mysite.com è pubblico e risolto dai DNS
www-1.mysite.com è privato e risolto solo localmente tramite file hosts.

20. Step2: Normalizzare ovvero eliminare le parti superflue
Va da se che se nelle pagine vi sono dei link pseudo realtivi, risulteranno non raggiungibili.
<%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
<%
String hostName=request.getServerName();
%>
<html>
<head>
<title>Server host name in jsp</title>
</head>
<body>
Host Name of server <%=hostName%>
</body>
</html>
Pagine come questa verrano servite attraverso il VH Privato dando un riferimento al nome
Privato www-1.mysite.com NON Raggiungibile

21. Step2: Normalizzare ovvero eliminare le parti superflue
In fine usiamo i Robots per garantirci che eventuali url lunghe orfane vengano
indicizzate.
Per farlo inseriamo un file chiamato robots.txt nella home root del nostro http
server., un file testuale composto nel modo seguente:
Un campo "User-agent" ed uno o più campi "Disallow".
Il campo User-agent serve ad indicare a quale robot/spider le direttive successive sono rivolte. La
sua sintassi è:
User-agent <duepunti> <spazio> <nome_dello_spider>
Il campo Disallow serve a indicare a quali file e/o directory non può accedere lo spider indicato nel
campo User-agent. La sintassi di questo campo è:
Disallow <duepunti> <spazio> <nome_del_file_o_directory>
Ad eempio
User-agent: googlebot
Disallow: /wps/wcm/connect/<libraryName>

22. Step2: Normalizzare ovvero eliminare le parti superflue
Esempio:
http://www.sonus.com
Riferimenti in: Portal Wiki
Downloads :
Librerie Apache x Windows / Sorgenti x Linux

23. Pagine di Cortesia

24. Pagine di cortesia:
ma lo sono veramente?
• Dire in modo chiaro che la pagina cercata non esiste
• Avere il medesimo look & fell del sito, in questo modo l'utente non
si sente perso e abbandonato....
• Considerare l'aggiunta di link ai tuoi articoli o post più popolari,
alla home page del tuo sito.
• Permettere agli utenti di segnalarci gli errori
• Essere certi che venga restituito il codice di errore, così Google
non la indicizza.....
• Valutare se inserire un widget che permetta la ricerca nel sito, e
fornire agli utenti informazioni utili per aiutarli a trovare le
informazioni di cui hanno bisogno.
• .........

25. Pagine di cortesia:
ma lo sono veramente?
Esempi:

26. Pagine di cortesia:
ma lo sono veramente?
Come fare: modifichiamo le configurazioni del nostro HTTP Server e
abbiamo vinto.
È sufficiente inserire le direttive appropriate
ErrorDocument 404 /bad_urls.html
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
Ma davvero è tutto qui?

27. Pagine di cortesia:
ma lo sono veramente?
Allora come mai il mio sito mi restituisce una pagina diversa?
E sopratutto chi la restituisce?
Le risorse Non-URL sono manipolate e trasformate all'interno del
livello di sicurezza di WebSphere Application Server (WSAS). Queste
definizioni sono specificate nel file web.xml nel file wps.ear e
wcm.ear. È necessario modificare le applicazioni per consentire la
gestione di una pagina di errore personalizzata.

28. Pagine di cortesia:
ma lo sono veramente?
Per cui tramite il WSAS l'application server intercetta l'errore e
fornisce la pagina di default, rispondendo comunque un 200 all'HTTP.
Il processo verifica il web.xml dell'applicazione e se trova una
specifica di gestione dell'errore, utilizza la pagina definita altrimenti
restituisce la standard.
Error 404: SRVE0190E: File not found:
/wccm/connect/SitiI......./home_page

29. Pagine di cortesia:
ma lo sono veramente?
Ora, è sufficente modificare il web.xml dell'applicazione e inserire la
mappatura della pagina di cortesia, il problema è che la
WebApplication da modificare sono due nello specifico:
• wps.ear
• wcm.ear
una soluzione per la parte protale consiste nel esguire l'UnDeploy
dell'applicazione, modificarla e Deployarla nuovamente, più
complicato farlo per il WCM, dovendo ricostruire manualmente tutti i
riferimenti EJB.

30. Pagine di cortesia:
ma lo sono veramente?
La modifica da insere nel web.xml è la seguente:
<error-page>
<error-code>404</error-code>
<location>/ep/e404.html</location>
</error-page>
un blocco per codice di errore da gestire

31. Pagine di cortesia:
ma lo sono veramente?
Ma se il nostro WCM, espone più siti, ad esempio soluzioni
Multi-Brand, siti as Service, etc etc. cosa succede?
Il nostro WSAS in caso di errore carica la nostra pagina. (Una per
Application Server)
Ma se abbiamo Look & Fell diversi come faccio?
Inseriamo una pagina che in realtà sollevi l'eccezione all'HTTP Server
che ha la vera pagina di cortesia da servire all'utente, mantenendo
l'eccezzione ed evitando che i crawler la indicizzino.

32. Pagine di cortesia:
ma lo sono veramente?

33. Pagine di cortesia:
ma lo sono veramente?
Esistono due modi leggermente diversi d'implementare la soluzione,
Dipendenti dal fatto che se opero in una soluzione Single-Node o in
un Cluster.
Fondamentalmente dovrò operare in posti diversi, ma facendo le
stesse cose, nel caso del Cluster devo, operare nel Deploy-Manger e
gestire la modifica tramite una fullSyncronize dei nodi, in modo che il
sitema “rideploy” le applicazioni sui nodi.
Va da se che se ho la brutta abitudine di “deployare” i temi e le jsp
custom direttamente nei nodi, le perderò inesorabilmente, ma qui il
porblema stà da un altra parte.

34. Pagine di cortesia:
ma lo sono veramente?
Ad esempio nel caso del Cluster modificare il file web.xml che si trova in
/profiles/<DMGRProfiles>/config/cells/applications/wps.ear/
deployments/wps/ wps.war/WEB-INF/web.xml
Cercare i tag
</mime-mapping>
<resource-ref>
Ed inserire tra i due tag la seguente struttura
<error-page>
<error-code>404</error-code>
<location>/ep/e404.html</location>
</error-page>

35. Pagine di cortesia:
ma lo sono veramente?
Preparare la pagina di gestione della “redirect” ed installarla nel file .ear
che stiamo gestendo
/ep/e404.html
Questa pagina avrà la struttura del tipo
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=/yourCourtesyPage.html"> <title>Not Found</title>
</head>
<body>
</body>
</html>

36. Pagine di cortesia:
ma lo sono veramente?
Ora non resta che preparare la nostra /yourCourtesyPage.html ed installarla
nell'http server in modo che venga caricata in caso di errore.
Eseguiamo la fullSyncronize dei nodi del cluster ed il gioco è fatto.
Riferimenti: Customize Error Page

37. Letture consigliate
WebSphere Portal 6x Infocenter
IBM Http Server Forum
Apache Http Server Project
WebSphere Portal Wiki
Apache at WebÞing
Apache Tutor

38. Grazie agli sponsor per aver reso possibile i
Dominopoint Days 2012!
Main Sponsor
Vad sponsor
Platinum sponsor
Gold sponsor