teo

This user hasn't shared any profile information

Posts by teo

Magento pagine prodotti duplicate

5

Magento è a detta di molti il migliore eCommerce Open Source e vi sono decine di motivi per dare credito a questa affermazione.

Non mi soffermerò sugli strumenti di configurazione e di vendita di Magento, ma vorrei fare un’analisi sull’aspetto SEO di questo buon eCommerce.

Il caso di studio è il seguente sito: Elio Usa e Getta, per il quale ho accettato una consulenza di posizionamento, soprattutto per poter finalmente approfondire gli aspetti tecnici di questo eCommerce gratuito.

Magento offre molte ottimizzazioni per i prodotti e per le categorie, con la possibilità di stabilire titoli e meta description ad hoc per ognuno di essi. Strumenti molto utili, ma prima di analizzare questo aspetto è stato indispensabile controllare la corretta indicizzazione del sito.

Il problema più grave riscontrato in questa configurazione di magento è stata la presenza di un gran numero di pagine duplicate di questo tipo:

dominio/prodotto-33.html

dominio/categoria1/prodotto-33.html

dominio/categoria2/prodotto-33.html

dominio/catalog/product/view/id/33.html

Come potete constatare, un singolo prodotto ha almeno 3 pagine duplicate, più ogni duplicato relativo ad ogni categoria aggiuntiva a cui è assegnato, a causa dell’impostazione “Use Categories Path for Product URLs = YES” in Sistema -> Configurazione -> Catalogo -> Ottimizzazioni per i motori di ricerca.

Analizzando meglio il codice si può però constatare che viene utilizzato il tag rel=canonical che spiega ai motori di ricerca quale sia la pagina giusta da indicizzare, ovvero /prodotto-33.html .

Questa soluzione non è però una vera ottimizzazione degli URL, in quanto non si sfruttano le keyword delle categorie che in certi casi sono molto utili.

Magento purtroppo non offre una soluzione al problema, dunque è stato necessario modificare dei file di sistema per poter avere l’url del prodotto come richiesto.

ATTENZIONE » SOLO PER UTENTI ESPERTI: Dal momento che è molto semplice rovinare un’installazione di magento applicando una modifica ai file del core, applicate la patch qui di seguito secondo le istruzioni solo se sapete esattamente cosa state facendo e solo dopo aver effettuato un backup completo dei file di magento e del database di magento. Declino ogni responsabilità per ogni danno derivante dall’applicazione della patch.

La patch proposta produce url contenenti le categorie a cui il prodotto appartiene, url ottimizzati e senza pagine duplicate.

ISTRUZIONI PER APPLICARE LA PATCH (SOLO PER UTENTI ESPERTI)

Anzichè modificare direttamente il file di sistema di magento Collection.php, che in caso di upgrade a versione successiva verrebbe sovrascritto, è consigliabile seguire questa procedura per l’override del file

  1. spostatevi nella directory in cui è presente magento
  2. create la directory app/code/local/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/
  3. copiate app/code/core/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/Collection.php in app/code/local/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/Collection.php
  4. spostatevi nella directory app/code/local/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/ e scaricate questo file di patch
  5. applicate la patch con il comando: patch <magento-url-non-duplicati.patch

A questo punto dovreste visualizzare un messaggio simile a questo:

patching file Collection.php
Hunk #1 succeeded at 978 (offset 425 lines).

In questo caso dovreste ora avere il file app/code/local/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/Collection.php modificato in modo da non presentare url duplicati (potrebbe essere necessario cancellare la cache).

Ricordatevi per finire di disabilitare i Canonical URL per i prodotti (Sistema -> Configurazione -> Catalogo -> Ottimizzazioni per i motori di ricerca -> Use Canonical Link Meta Tag For Products = NO) e di fare tutti i redirect 301 necessari (ad esempio da /prodotto-33.html a /categoria/sottocategoria/prodotto-33.html)

 

Casinò on line: Nicchie competitive

2

Una nicchia di mercato altamente competitiva in cui è possibile analizzare le tecniche SEO degli esperti è sicuramente quella dei casinò on line e del gioco d’azzardo in generale.

A differenza dell’intrattenimento per adulti, in cui la stragrande maggioranza dei webmaster utilizza tecniche gray o blackhat, nel settore dei giochi online si possono trovare svariati “stili” e tecniche di posizionamento sui motori di ricerca. (continua…)

Controllo disco partizione crittografata loop-aes

0

Quando si ha a che fare con dati sensibili degli utenti è indispensabile disporre di sistemi crittografici forti, siano architetture complesse o semplici precauzioni da occhi indiscreti.

Un caso tipico è quello di crittografare un disco o una partizione con loop-aes: vi sono centinaia di guide in rete e non mi dilungherò a riguardo. Segnalo a titolo di esempio la guida gentoo per loop-aes e lvm2.

Pochissime guide ci dicono però come fare un controllo dei dischi crittografati con fsck.

Nell’esempio la mia partizione è in /dev/loop3 : modificatela in base al vostro loop.

losetup -F /dev/loop3
fsck -t ext2 -f -y /dev/loop3
losetup -d /dev/loop3

È importante un controllo periodico, soprattutto in seguito a crash del sistema o vuoti improvvisi di corrente.

Joomla: articoli orfani non collegati a menu

0

Uno dei bug più fastidiosi delle vecchie versioni di Joomla in versione SEF, bug ancora presente in moltissimi plugin scritti in pessimo php e con scarso supporto SEF, riguarda la creazione di pagine duplicate per articoli non assegnati ad alcun menù oppure non presenti in alcuna categoria collegata direttamente ad un menù.

Commettere l’errore di non controllare plugin di terze parti (oppure di utilizzare versioni vecchie di Joomla) avendo abilitato gli URL search engine friendly può essere fatale, dato che questi articoli orfani possono creare montagne di pagine duplicate.

Non esistono al momento estensioni di Joomla per trovare questi articoli orfani non associati a nessun menù, ma con una semplice query SQL (da eseguire su shell o in phpMyAdmin) potete iniziare ad avere delle indicazioni importanti.

La seguente interrogazione SQL incrocia i dati delle tabelle jos_menu e jos_content e vi indica tutti gli articoli non associati direttamente ad un menù.


SELECT * FROM `jos_content` AS co WHERE co.id NOT IN (SELECT c.id FROM `jos_menu` as m join `jos_content` as c on m.link = concat('index.php?option=com_content&view=article&id=',c.id));

 

Tenete però presente che la query qui sopra vi inserirà tra i risultati anche gli articoli (decine, centinaia o migliaia) che hanno un loro url univoco e che non presentano potenziali problemi, perchè associati ad una voce di menù di tipo “aspetto categoria” o “aspetto categoria blog”, come può essere ad esempio una sezione NEWS.

Se avete una soluzione per rimuovere questi “falsi positivi” segnalatemelo. La soluzione data da un sito a pagamento (expert-exchange) qui di seguito NON funziona.

SELECT * FROM `jos_content` AS co WHERE co.id NOT IN (SELECT c.id FROM `jos_menu` as m join `jos_content` as c on m.link = concat('index.php?option=com_content&view=article&id=',c.id))
AND co.catid NOT IN (SELECT SUBSTRING_INDEX(`link`,'=',-1) FROM `jos_menu` WHERE `link` LIKE 'index.php?option=com_content&view=&category%' AND `published` = 1)

Link esterni rotti – External Broken Links

0

Grazie a Google Webmaster Tools ho notato in uno dei siti che seguo, in una nicchia molto concorrenziale e ad altissima resa economica, un numero elevato di LINK A PAGINE INESISTENTI che riportano l’errore 404 – page not found.

Dato che esistono delle penalizzazioni da parte di google per un alto numero di pagine non esistenti mi sono precipitato a capire il perchè, pensando subito ad un bug di Joomla. Quello che ho trovato invece è che i link provengono da altri domini che puntano a pagine inesistenti.

Dal momento che questi link provengono da siti di spam, forum infestati da spammers e quant’altro, e dato che le pagine verso cui i link puntano sono volontariamente simili ma non uguali a quelle di punta del mio sito, ho capito di essere sotto uno strano tipo di attacco di link spamming.

Stando a quanto sostengono gli esperti, avere “external broken links“, cioè link errati provenienti da siti esterni, non è un problema, in quanto se lo fosse sarebbe davvero facile far penalizzare un altro sito web.

Tuttavia so di avere a che fare con uno spammer professionista, un blackhat seo che riesce continuamente a posizionare il suo sito di 10 pagine davanti a colossi di 10.000 pagine, aggirando i controlli di Google su spam e cloaking, per cui il sospetto che questo deliberato inserimento di link sbagliati su siti di spam possa portare il mio sito ad una penalità mi tiene in allarme.

Come reagire a questo strano attacco di link spamming?

La mia prima reazione è stata quella di creare una pagina ad hoc per ogni link non trovato, giovando così del prezioso lavoro fatto dallo spammer.

Mi è anche stato suggerito da alcuni esperti di rispondere alla richiesta di GoogleBot con un http status code 410 – Gone, ma leggendo le specifiche credo sia preferibile evitare questa soluzione.

Essendo abbastanza paranoico sul rischio di penalizzazioni di Google ho quindi deciso di lasciare le cose esattamente come stanno, tenendo d’occhio la situazione quotidianamente.

Se avete avuto esperienze analoghe con spammer che hanno tentato di danneggiare il vostro posizionamento con link di spam, vi prego di segnalarlo nei commenti.

Rimuovere pagine duplicate da VirtueMart

3

VirtueMart è un componente aggiuntivo Open Source per Joomla che permette di installare sul vostro sito web un carrello elettronico, in modo da realizzare un vero e proprio eCommerce con il vostro sito Joomla.

Virtue Mart, sebbene sia gratuito, è un componente molto complesso e a mio avviso completo, in continua evoluzione grazie alla vasta comunità di sviluppatori ed utilizzatori che ne sono interessati.

A livello SEO però VirtueMart ha dei grandissimi problemi, almeno per quanto riguarda le versioni da me testate: VirtueMart crea un numero spropositato di pagine duplicate, problema molto grave per chi guarda al proprio sito internet nell’ottica del posizionamento sui motori.

Nel sito oggetto di studio (Veramente Naturale, negozio di cosmetici naturali) sono stati innanzitutto abilitati gli URL SEF nel pannello di controllo di Joomla agganciando VirtueMart all’url /shop : le pagine duplicate erano esattamente quelle riportate qui sotto. Il cliente aveva inoltre creato manualmente dei link invertendo l’ordine dei parametri della query string, in modo che vi fossero ulteriori versioni duplicate con i parametri invertiti.

Per capire subito di cosa parliamo, vi propongo un esempio concreto di come VirtueMart crea pagine duplicate, ovvero molte versioni identiche dello stesso prodotto

  1. /index.php?option=com_virtuemart&page=shop.browse&category_id=29&lang=it&Itemid=233&vmcchk=1
  2. /index.php?option=com_virtuemart&page=shop.browse&category_id=29&lang=it&Itemid=233
  3. /index.php?option=com_virtuemart&page=shop.browse&category_id=29&lang=it
  4. /index.php?option=com_virtuemart&page=shop.browse&category_id=29
  5. /shop?page=shop.browse&category_id=29&lang=it&Itemid=233&vmcchk=1
  6. /shop?page=shop.browse&category_id=29&lang=it&Itemid=233
  7. /shop?page=shop.browse&category_id=29&lang=it
  8. /shop?page=shop.browse&category_id=29

Come potete vedere, VirtueMart crea per la stessa pagina 8 versioni identiche. Sebbene Google sia in grado di stabilire se i parametri della query string siano necessari o no per identificare univocamente la pagina, alcune varianti duplicate restano, e la nostra pagina risulta di scarso valore agli occhi dei motori di ricerca.

Vi sono alcune soluzioni per ovviare al problema: la prima comporta l’installazione di plugin aggiuntivi per Joomla che sono in grado di trasformare VirtueMart nella versione con URL SEF , la seconda richiede la modifica del file .htaccess per rimuovere la maggior parte delle pagine duplicate grazie all’utilizzo dei redirect permanenti (redirect 301 di mod_rewrite di Apache).

1- Utilizzo di plugin SEF di Joomla

sh404SEF è a detta di molti esperti il migliore plugin SEF per VirtueMart. Personalmente preferisco evitare l’utilizzo di plugin esterni e limitarmi al core SEF di Joomla, pertanto passerò alla seconda soluzione, quella ingegneristicamente più interessante, molto difficile da trovare sul web.

2- Modifica del file .htaccess e mod_rewrite

La soluzione che proporrò nelle prossime righe è altamente complessa ed è intesa unicamente ad offrire spunti a chi già conosce .htaccess e mod_rewrite.

In questo caso gli URL di VirtueMart non sono veri e propri URL SEF, dal momento che permangono alcuni parametri nella query string. Tuttavia ho personalmente riscontrato ottimi risultati a livello SEO anche senza gli URL SEF su virtuemart, dunque rimango del parere che sia meglio affidarsi al proprio ingegno per risolvere un problema di duplicazione delle pagine piuttosto che affidarsi a plugin che non conosciamo.

Iniziamo a vedere le righe di codice da inserire nel file .htaccess per rimuovere alcuni dei parametri della query string non necessari. Dopo il codice cercherò di spiegare il significato delle istruzioni, numerate da 1 a 9 per comodità.

  1. RewriteEngine On
  2. RewriteCond %{QUERY_STRING} (.*)(^Itemid=[a-zA-Z0-9]+&?|^&Itemid=[a-zA-Z0-9]+&|&Itemid=[a-zA-Z0-9]+)(&?.*)
  3. RewriteRule (.*) %{REQUEST_URI}?%1%3 [L,R=301]
  4. RewriteCond %{QUERY_STRING} (.*)(^lang=[a-zA-Z0-9]+&?|^&lang=[a-zA-Z0-9]+&|&lang=[a-zA-Z0-9]+)(&?.*)
  5. RewriteRule (.*) %{REQUEST_URI}?%1%3 [L,R=301]
  6. RewriteCond %{QUERY_STRING} ^(.+&)option=com_virtuemart(.+)?$ [NC]
  7. RewriteRule ^index\.php$ http://%{HTTP_HOST}/shop$1?%1%2 [R=301,L]
  8. RewriteCond %{QUERY_STRING} ^(.+&)?option=com_virtuemart&(.+)?$ [NC]
  9. RewriteRule ^index\.php$ http://%{HTTP_HOST}/shop$1?%1%2 [R=301,L]

Vediamo il significato di ogni istruzione.

  1. RewriteEngine On
    Indica a Apache di utilizzare mod_rewrite per la riscrittura degli URL
  2. RewriteCond %{QUERY_STRING} (.*)(^Itemid=[a-zA-Z0-9]+&?|^&Itemid=[a-zA-Z0-9]+&|&Itemid=[a-zA-Z0-9]+)(&?.*)
    Ricerca all’interno della query string la stringa Itemid= , inutile utilizzando VirtueMart con URL SEF
  3. RewriteRule (.*) %{REQUEST_URI}?%1%3 [L,R=301]
    Rimuove la stringa cercata dall’URL con un redirect permanente
  4. RewriteCond %{QUERY_STRING} (.*)(^lang=[a-zA-Z0-9]+&?|^&lang=[a-zA-Z0-9]+&|&lang=[a-zA-Z0-9]+)(&?.*)
    Ricerca la stringa lang= nella query string, aggiunta dal plugin Joomfish non in uso
  5. RewriteRule (.*) %{REQUEST_URI}?%1%3 [L,R=301]
    Rimuove la stringa cercata dall’URL con un redirect 301 permanente
  6. RewriteCond %{QUERY_STRING} ^(.+&)option=com_virtuemart(.+)?$ [NC]
    Ricerca la stringa option=com_virtuemart in mezzo o alla fine della query string
  7. RewriteRule ^index\.php$ http://%{HTTP_HOST}/shop$1?%1%2 [R=301,L]
    Sostituisce la stringa option=com_virtuemart con /shop e rimuove /index.php, utilizzando un 301 permanent redirect
  8. RewriteCond %{QUERY_STRING} ^(.+&)?option=com_virtuemart&(.+)?$ [NC]
    Ricerca la stringa option=com_virtuemart all’inizio della query string
  9. RewriteRule ^index\.php$ http://%{HTTP_HOST}/shop$1?%1%2 [R=301,L]
    Sostituisce la stringa index.php?option=com_virtuemart con shop, usando un redirect 301

Ci tengo a sottolineare che questa soluzione va adattata alle vostre esigenze, e che non basta un copia-incolla per risolvere il vostro problema delle pagine duplicate su VirtueMart.

Grazie a tutti questi rewrite riusciamo così a passare dall’url /index.php?option=com_virtuemart&page=shop.browse&category_id=29&lang=it&Itemid=233 all’url /shop?page=shop.browse&category_id=29

Consiglio ai non esperti di prestare grande attenzione nella modifica di .htaccess: invece di rimuovere pagine duplicate, rischiate seriamente di introdurne di nuove e, soprattutto, di compromettere le funzionalità di VirtueMart.

CentOS 5: aggiornare php alla versione 5.3

0

Con il sistema operativo CentOS 5 ogni tanto si ha la necessità di disporre dell’ultima versione di un software e la soluzione non è immediata.
Nel caso oggetto di studio in questo articolo, si andrà ad aggiornare php dalla versione 5.1 alla versione 5.3 (in realtà sarebbe stato sufficiente aggiornarla alla 5.2 per risolvere problemi di compatibilità con un’applicazione web, l’estensione per Joomla! Glossary, che crea un glossario dei termini utilizzati sul sito in Joomla).
Per risolvere il problema, è necessario aggiornare il repository in cui yum, il sistema di gestione dei pacchetti di CentOS, cerca versioni aggiornate dei software.
Operiamo nel seguente modo, installando i pacchetti epel (necessario per la gestione delle dipendenze) e il repository remi.

Importante: prima di digitare i comandi che verranno proposti, effettuare un backup completo di tutti i database.

Questi i comandi :

# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
# rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Una volta installati i pacchetti, digitare il seguente comando per aggiornare php, abilitando il repository remi:

#yum –enablerepo=remi update php

Potrebbe capitare di incorrere nel seguente errore:

Transaction Check Error:
file /etc/my.cnf from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/charsets/Index.xml from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/charsets/cp1250.xml from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/czech/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/danish/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/dutch/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/english/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/estonian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/french/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/german/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/greek/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/hungarian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/italian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/japanese/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/korean/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/norwegian-ny/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/norwegian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/polish/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/portuguese/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/romanian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/russian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/serbian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/slovak/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/spanish/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/swedish/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386
file /usr/share/mysql/ukrainian/errmsg.sys from install of mysql-libs-5.1.50-2.el5.remi.i386 conflicts with file from package mysql-5.0.77-4.el5_5.3.i386

In questo caso è necessario aggiornare mysql, che provvederà automaticamente ad aggiornare php alla versione 5.3.3

# yum –enablerepo=remi update mysql

Completato l’aggiornamento sarà necessario riavviare mysql e php, affinchè il webserver apache utilizzi l’ultima versione installata:

# service mysqld restart
# service httpd restart

Potrete ora controllare la versione di php e mysql con i seguenti comandi:

# php –version

# mysql –version

Joomla: INVALID TOKEN

5

Joomla è un grande CMS, uno dei migliori tra quelli disponibili Open Source.
Purtroppo ci sono però dei problemini che ancora non sono stati sistemati, come ad esempio il famigerato errore Error Loading Modules o quello di cui ci occupiamo ora: INVALID TOKEN.

Il messaggio compare in varie occasioni, in particolare in momenti critici come l’invio di una mail di contatto e all’atto del login nel frontend del sito.

Nel caso del problema nell’invio di email di contatto il componente che viene coinvolto è com_contacts.

Come al solito questo messaggio è molto generico ed anche utilizzando la funzione di debug del sistema di Joomla non è possibile ricavare delle informazioni esaurienti.

La soluzione al problema INVALID TOKEN (un workaround) è disabilitare la cache di Joomla seguendo il percorso SITO -> CONFIGURAZIONE -> SISTEMA ed impostando il valore di CACHE a NO.
A questo punto vi sarà sufficiente cancellare la cache seguendo il percorso STRUMENTI -> PULISCI CACHE : selezionate tutti gli elementi e fate click sul bottone CANCELLA.

A livello tecnico c’è un errore nella gestione dei token di sessione quando la cache è abilitata: una patch da applicare al core di Joomla è disponibile qui: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=19435

Il mio consiglio è di non utilizzare la cache se non indispensabile, almeno finchè non verrà rilasciata una versione ufficiale di Joomla che ripari il problema.

Chi è il migliore esperto SEO?

2

Il team di Google ha da poco realizzato un questionario di medio livello per scoprire chi è il migliore esperto SEO del mondo.

In realtà questo questionario serve ai webmaster per scoprire in modo “divertente” se le proprie conoscenze di base su Google sono buone.

Il questionario può essere trovato in questa pagina e sarà disponibile fino a Mercoledì 27 Gennaio 2010.

Gli esperti di SEO difficilmente sbaglieranno più di una risposta ed impiegheranno circa 10 minuti. Webmaster meno esperti invece impiegheranno fino a mezzora e con tutta probabilità faranno molta fatica a rispondere correttamente al 50% delle domande poste.

Ovviamente se avete spirito competitivo potete anche “barare” cercando le risposte che non sapete (o forse anche l’intero questionario) con il motore di ricerca stesso. Ma non è questo lo spirito del sondaggio.

Scoprite se siete dei buoni esperti seo o no!

Migliorare prestazioni Joomla

2

Dopo le anticipazioni di Matt Cutts di qualche tempo fa, è apparso chiaramente sul blog di google che in futuro la velocità di un sito ne influenzerà il posizionamento ed il trust da parte del motore di ricerca.

In particolare è stato pubblicato un interessante post sulle prestazioni intitolato “quanto è veloce il tuo sito?”, che illustra un nuovo tool disponibile in via sperimentale all’interno di google webmaster tools.

Questo tool analizza il tempo di caricamento delle pagine del vostro sito, sulla base dei dati forniti dalla Google Toolbar e fa un paragone tra il vostro sito e tutti gli altri siti analizzati.

Per fare un esempio, un sito di un nostro cliente al quale è stata fatta una consulenza seo è risultato ottimo dal punto di vista SEO, ma con dei tempi di caricamento disastrosi.
Questo è il messaggio che compare all’interno di Google Webmaster Tools:

Panoramica delle prestazioni del sito

In media, il caricamento delle pagine nel tuo sito richiede 7,2 secondi (ultimo aggiornamento: 03/dic/2009). È più lento del 86% dei siti. Il seguente grafico mostra le variazioni nei tempi di caricamento medi delle pagine del tuo sito nel corso degli ultimi mesi. Come riferimento, mostra anche il valore del 20° percentile in tutti i siti, distinguendo i tempi di caricamento lenti da quelli veloci.

Come noterete, il risultato di questo test è disastroso: il sito è molto lento.

Sono stato incaricato personalmente di analizzare questo grave problema della lentezza del sito e di trovare una soluzione per rendere il sito più veloce e, forse, maggiormente appetibile da Google.

L’analisi delle prestazioni del sito è iniziata utilizzando l’estensione per Firefox fornita da Google per i benchmark: Page Speed.

È bastato apportare delle modifiche al cms (Joomla 1.5 in questo caso) ed al file di configurazione di Apache per ottenere dei risultati interessanti.

Per migliorare le prestazioni di velocità di Joomla 1.5 è sufficiente configurarlo come si deve:

  • Attivare il plugin System – Cache

Joomla offre un plugin per la cache delle pagine, in modo da rendere un cms basato su database molto più simile ad un normale sito fatto con html statico.

Per default però il plugin è disattivato: sarà sufficiente attivarlo, impostare un tempo di cache abbastanza lungo ed abilitare la browser caching per ottenere dei buoni risultati

  • Abilitare la Cache di Joomla

Per abilitare la cache di Joomla seguire il percorso Sito -> Configurazione -> Sistema  , selezionare Sì alla voce Cache ed impostare un tempo abbastanza lungo a seconda delle vostre esigenze.

  • Abilitare la compressione Gzip di Joomla

Per abilitare la compressione Gzip di Joomla seguire il percorso Sito -> Configurazione -> Server e scegliere Sì alla voce Compressione pagine GZIP.

  • Installare CssJsCompress

CssJsCompress è un plugin per comprimere attraverso Gzip i file CSS e Javascript. Lo trovate all’indirizzo http://extensions.joomla.org/extensions/site-management/cache/7350 e vi permette di avere una buona compressione dei file CSS e Javascript senza dover configurare nulla. Per attivarlo andate in Estensioni -> Gestione Plugin e aprite System – CssJsCompress , selezionate alle voci Optimize CSS Files, Optimize JavaScript Files, GZip JavaScript and CSS e salvate.

Per quanto riguarda Apache, un accorgimento molto importante è quello di attivare il caching a livello del server.

Aprite il vostro file di configurazione (httpd.conf) ed inserite le seguenti righe:

ExpiresActive On
ExpiresByType image/png “now plus 60 days”
ExpiresByType image/jpeg “now plus 60 days”
ExpiresByType image/gif “now plus 60 days”
ExpiresByType application/javascript “now plus 60 days”
ExpiresByType application/x-javascript “now plus 60 days”
ExpiresByType text/javascript “now plus 60 days”
ExpiresByType text/css “now plus 60 days”

Per maggiori informazioni su Apache e la cache: Apache Mod_Expires.

teo's RSS Feed
Go to Top