Occhio che non tutti i crawler seguono le regole del robots.txt
Le direttive inserite nel robots.txt non sono una regola assoluta, ma solo un suggerimento.

Se si vuole lavorare online su sottocartelle ed evitare l'indicizzazione, è più efficace utilizzare il tag <meta name="robots" content="noindex">
Su Joomla è sufficiente impostare Sistema -> Configurazione Globale -> Sito -> Robots su "noindex, nofollow"

Prevenire è meglio che curare.
A me è capitato di vedere file disallow su robots.txt ma comunque indicizzati e presenti su qwant e yahoo.

@webman I Web asset sono una manna dal cielo.
Io li sto usando senza ritegno da quando sono stati implementati.

@teopieri Qui un mio articolo proprio su come usarli per caricare un nuovo css:

https://www.htmlcrusco.it/blog/web-asset-il-modo-giusto-di-aggiungere-javascript-e-css-a-joomla

@ste981 Apache in https ha bisogno di certificato, anche in localhost.
Se ti va di impicciarti con la configurazione di un certicato locale o di barbatrucchi per evitarlo, in rete trovi tutto il materiale possibile... o almeno per Linux c'è di tutto, per Windows credo anche, ma non ti so dire sicuro.

Altrimenti fai come faccio io: in locale lavoro in http e passo in https quando metto online. Mai avuto problemi.

Se ti serve disabilitare https sul tuo sito in locale, vai sul file configuration.php di Joomla e imposta

public $force_ssl = 0;

A meno che tu non abbia regole sull'htaccess, dovrebbe andare.
Altrimenti devi togliere anche quelle.

EDIT: scusami, ho letto ora che ti va automaticamente in https anche sulla root del localhost.
In questo caso non so se forzando il file di configurazione come ho scritto sopra, possa risolvere qualcosa.

Appena possibile organizzo una manifestazione NO-CACHE.

Mmmh.
Credo che la stessa domanda che mi sto ponendo io se la sia posta il crawler di Google:
"Perché per la home page mi sta suggerendo l'indirizzo https://www.graficaeditoriale.it/index.html e non https://www.graficaeditoriale.it/ ?"

EDIT: ma è un sito fatto con Joomla?

Ciao Pietro.
No, non solo non è sufficiente, ma è proprio sbagliato.

Il plugin si comporta erroneamente allo stesso modo di tanti template di terze parti, impostando il link canonical come l'indirizzo attuale della pagina.
Purtroppo non è così, come ben sanno tutti quelli che si occupano di SEO.

Nei CMS la stessa pagina può essere raggiunta da diversi URL, molti dei quali non mappati nell'albero di navigazione del sito, ma trovati sicuramente dai crawler.

In questi casi lo stesso contenuto risulta raggiungibile da più indirizzi, ed è qui che entra in gioco il canonical, che non deve essere l'indirizzo che sta visitando il crawler, ma quello presente sull'albero di navigazione del sito, sia direttamente (link diretto al contenuto) che indirettamente tramite una relazione padre-figlio, come quella categoria-articolo.

A questo punto credo dipenda da qualche estensione, oppure dal contenuto dell'articolo.
Hai provato impostando nessun editor e scrivendo il codice HTML senza usare TinyMCE?

Come ti ha suggerito @jabba , devi usare la sticky position.
Per il tuo sito, dovresti risolvere aggiungendo queste righe al CSS per la classe .navigation

z-index: 1000 !important;
position: sticky;
top: -5px;
background-color: #fff;

Facci sapere.

Ti faccio un esempio pratico.

Sul tuo sito hai una categoria di articoli che si chiama "Joomla extensions".
Di questa categoria fanno parte due articoli con i seguenti alias:

• plugin-social-per-joomla
• componente-viaggi-per-joomla

Il tuo menu di navigazione prevede una voce che punta alla categoria "Joomla extensions" e due sotto voci di menu con alias "plugin-social" e "componente-viaggi" che puntano ai due articoli citati sopra.

Ora che succede? Che ogni articolo può essere raggiunto da due URL:

/joomla-extensions/plugin-social-per-joomla
/joomla-extensions/plugin-social

/joomla-extensions/componente-viaggi-per-joomla
/joomla-extensions/componente-viaggi

Con il plugin system sef di Joomla, avrai un canonical diverso a seconda da quale indirizzo arrivi, e quindi - agli occhi dei motori di ricerca -, contenuti duplicati.

Un plugin che imposta correttamente il canonical invece, ti piazza sulla pagina sempre lo stesso canonical.
In questo caso quello giusto è, per ovvi motivi, quello linkato da menu, che ha precedenza su quello di categoria.

N.B. Ho messo solo due duplicati URL per articolo, ma ce ne sono molti di più.
Questo ad esempio è un altro formato che i crawler usano per trovare contenuti tramite id articolo e id categoria:

https://miosito.com/?view=article&id=8&catid=10

@Vale Se ti perde la formattazione anche senza editor, allora non è un problema specifico TinyMCE ma di qualche impostazione Joomla.
Se con JCE funziona, significa che questo fa un bypass (o meglio, se ne sbatte) di tale impostazione.

Bene che intanto puoi lavorare!

Ciao

Alla fine delle modifiche dovresti avere questa classe .navigation nel file templates/protostar/css/template.css

.navigation {
	padding: 5px 0;
	border-top: 1px solid rgba(0,0,0,0.075);
	border-bottom: 1px solid rgba(0,0,0,0.075);
	margin-bottom: 10px;
	z-index: 1000 !important;
	position: sticky;
	top: -5px;
	background-color: #fff;
}

Gli import vanno inseriti nel tuo user.css e caricano le regole che hai definito in altri fogli di stile.
Questo ti permette di splittare le classi css in più file (creando l'ordine che cerchi) e richiamarle poi in un unico file (lo user.css).

Il nome del file è sempre quello, cambia la query string sull'URL (?v=idunivoco).

La cache del browser non può agire sui contenuti delle variabili in memoria, ma solo su quelle dello storage locale (vedi cookie).
In generale non interpreta gli script ma si limita a fare il caching della risposta in HTML e delle eventuali risorse statiche esterne (js, css, immagini, video).

Se il player audio html prevede l'impostazione di preload, è probabile che memorizzi qualcosa nello storage locale.
Il tuo codice php restituisce un HTML privo di file audio, perché quest'ultimo viene caricato successivamente al caricamento della pagina tramite JS.
Questo metodo crea pagine HTML che sono tutte uguali e quindi il browser non trovando differenze con la versione memorizzata nello storage locale, tende a caricare le risorse che trova nella cache.

Per esserne sicuri bisognerebbe vedere l'algoritmo di cache del browser, ma se con preload="none" funziona, allora molto probabilmente è così.

Puoi fare anche un'altra prova.
Lato PHP fai restituire il tag <audio> già con un file random impostato... solo il primo, poi gli altri puoi continuare a gestirli con JS.
Con il file già impostato, l'HTML restituito varia perché cambia il nome del file. Di conseguenza il ricorso alla cache dovrebbe avvenire solo se il nome del file è uguale a quello già in cache.

Su Joomla 5.4.1, gestione sessioni su "Database", ho eseguito lo scheduler "Session GC" e la tabella #__session è stata pulita correttamente.

Con gestione sessioni su "File system" ho scoperto che non funziona più una cippalippa: né il Session GC, e né il mio cron tab personale.
Se riesco a trovare soluzione, vi aggiorno.

@robjrobj
Niente a che vedere con bootstrap-table.
Secondo me molto meglio la tua soluzione.

Avevo implementato qualcosa del genere con BS (card e panel) per visualizzare tutte le statistiche e i risultati di un campionato di vela.
Secondo me è la migliore soluzione quando sei su mobile e hai dei tabelloni del genere!

@brusamolino Ciao. I feed funzionano solo per gli articoli, e quindi il per il componente com_content, mentre la tua pagina visualizza contenuti dal componente com_contact

Ciao.
Per avere la tabella delle sessioni sempre pulita ti consiglio di chiamare l'apposito task session:gc di Joomla.
Dal pannello di controllo dell'hosting devi impostare un cron tab che va ad eseguire il task ogni x tempo.
Io l'ho impostato ad ogni ora.

Se non sai come si fa, contatta il tuo hosting e digli che hai bisogno di un cron tab che esegua questo file php ogni ora (o quanto pensi che sia più consono al tuo sito web):

cli/joomla.php session:gc

Nel mio caso ho dovuto usare questa istruzione:

sp-php public_html/cli/joomla.php session:gc

ma in base all'hosting può cambiare sia il path che l'eseguibile sp-php.

Ciao.
Per la pulizia delle sessioni di conviene utilizzare l'apposito task session:gc
Io nei miei hosting lo eseguo in questo modo:

sp-php public_html/cli/joomla.php session:gc

Se vuoi utilizzare il Cron web, anche se non uso Aruba, mi sembra dal tuo screenshots che sia tutto ok.
Altrimenti potresti provare con "Esegui un comando" facendo una chiamata curl.

curl -s --request GET "https://greenreport.it/component/ajax/...blablabla"

EDIT: ho visto ora che ti avevo già suggerito session:gc https://community.joomla.it/topic/627/pulizia-delle-sessioni-db-mysql-joomla/3?_=1767975921942