@Sermatica said:

Ciao
il sito vedo che è ben indicizzato, la pagina da te citata è senza testo. Andrebbe messo qualche riga in alto.

Oltre a questo cliccando sui singoli progetti le url vengono ristrette mettendo nelle Url #!. Perchè?

Per quanto riguarda url con #! purtroppo non l'ho fatto io ..... chiesto il motivo : e mi ha risposto che è la struttura del CMS ..qualche dubbio ce l'ho ; però se digiti ad esempio
seccosistemi .com/it/realizzazioni#!/casa-bokan

la immetti su google, mi dà come risposta seccosistemi.com/it/realizzazioni/casa-bokan senza #! ...

quindi indicizza lo stesso ...ma potrebbe essere questo il problema per le immagini?

Ciao
vedi se si può risolvere il problema delle url, come ti dicevo devi aggiungere del testo.

@Sermatica said:

Ciao vedi se si può risolvere il problema delle url, come ti dicevo devi aggiungere del testo.

Il problema delle url non si risolve con questo CMS..Purtroppo ..per il testo ora sento il webmaster..

Se faccio inserire i microdati , secondo te , può migliorare la situazione?

Grazie

Ciao
sistema i punti e poi ne riparliamo

@Sermatica said:

Ciao
il sito vedo che è ben indicizzato, la pagina da te citata è senza testo. Andrebbe messo qualche riga in alto.

Oltre a questo cliccando sui singoli progetti le url vengono ristrette mettendo nelle Url #!. Perchè?

Se guardi il sorgente della pagina, vedrai che gli URL dei link sono normali, motivo per cui Google indicizza le pagine normalmente. Ma c'e' del JavaScript che intercetta i clicks su quei link e invece di fare un full load delle pagine, le carica con XHR (Ajax), usando il metodo del fragment identifier (#) per distinguere tra le pagine caricate in quel modo in successione. Poi server-side il sito e' fatto in modo tale da servire le pagine correttamente sia con lo URL normale che con quelli aventi il fragment identifier. Questo meccanismo e' tipico delle "single page apps".

@SkyLinx said:

Se guardi il sorgente della pagina, vedrai che gli URL dei link sono normali, motivo per cui Google indicizza le pagine normalmente. Ma c'e' del JavaScript che intercetta i clicks su quei link e invece di fare un full load delle pagine, le carica con XHR (Ajax), usando il metodo del fragment identifier (#) per distinguere tra le pagine caricate in quel modo in successione. Poi server-side il sito e' fatto in modo tale da servire le pagine correttamente sia con lo URL normale che con quelli aventi il fragment identifier. Questo meccanismo e' tipico delle "single page apps".

Grazie SkyLinx ...dunque è normale la sintassi ? vedi delle problematiche nel sito per cui le img vengono indicizzate lentamente ? Grazie mille

@SkyLinx said:

Se guardi il sorgente della pagina, vedrai che gli URL dei link sono normali, motivo per cui Google indicizza le pagine normalmente. Ma c'e' del JavaScript che intercetta i clicks su quei link e invece di fare un full load delle pagine, le carica con XHR (Ajax), usando il metodo del fragment identifier (#) per distinguere tra le pagine caricate in quel modo in successione. Poi server-side il sito e' fatto in modo tale da servire le pagine correttamente sia con lo URL normale che con quelli aventi il fragment identifier. Questo meccanismo e' tipico delle "single page apps".

Ok, ma in questo caso la nuova pagina dovrebbe fare canonical sull'url corretta. Non è sbagliato com'è ora ma a mio avviso va a cozzare con una buona ottimizzazione Seo.

@marconovita said:

Grazie SkyLinx ...dunque è normale la sintassi ? vedi delle problematiche nel sito per cui le img vengono indicizzate lentamente ? Grazie mille

Non vedo alcun problema "evidente", perche' gli IMG tag hanno un URL normale, l'"alt" attribute con una descrizione dell'immagine, e anzi una cosa ottima e' che usano anche gli attributi "srcset" (accompagnati dai corrispettivi "source" tag) che vengono usati per fornire al browser diverse immagini per diverse risoluzioni, per responsive design. Questo e' ottimo. Significa che il browser carichera' la versione dell'immagine specificata piu' adatta alla risoluzione usata, il che si traduce in un sito che carica piu' velocemente soprattutto su mobile. Considerando che la velocita' del sito e' per Google un ranking signal, questo aiuta anche dal punto di vista SEO.

L'HTML che questo CMS genera non e' affatto male.

@Sermatica said:

Ok, ma in questo caso la nuova pagina dovrebbe fare canonical sull'url corretta. Non è sbagliato com'è ora ma a mio avviso va a cozzare con una buona ottimizzazione Seo.

GLi URL con fragment identifier vengono attivati soltanto quando si fa click vero e proprio sui link, e non vengono listati / linkati da nessuna parte nel sito per quello che posso vedere, quindi non c'e' bisogno di canonical URL perche' Google non vede gli URL con fragment identifier.

@SkyLinx said:

Non vedo alcun problema "evidente", perche' gli IMG tag hanno un URL normale, l'"alt" attribute con una descrizione dell'immagine, e anzi una cosa ottima e' che usano anche gli attributi "srcset" (accompagnati dai corrispettivi "source" tag) che vengono usati per fornire al browser diverse immagini per diverse risoluzioni, per responsive design. Questo e' ottimo. Significa che il browser carichera' la versione dell'immagine specificata piu' adatta alla risoluzione usata, il che si traduce in un sito che carica piu' velocemente soprattutto su mobile. Considerando che la velocita' del sito e' per Google un ranking signal, questo aiuta anche dal punto di vista SEO.

L'HTML che questo CMS genera non e' affatto male.

Utilizzando i microdati per le immagini, per tua esperienza , la situazione potrebbe migliorare o è ininfluente? Ti ringrazio

@marconovita said:

Utilizzando i microdati per le immagini, per tua esperienza , la situazione potrebbe migliorare o è ininfluente? Ti ringrazio

Per quello che so, aiutano Google nel crawling e basta, cioe' suggeriscono a Google il significato di un elemento nella pagina ma Google non tiene conto di questo nel ranking. Altrimenti uno potrebbe ottenere un effetto simile - per risultato - a keyword stuffing (che non e' buona cosa) abusando di microdata.