Das Problem dürfte einfach zu lösen sein, wenn Du siehst was die vermutliche Ursache ist... 🙃

Ursache der Einstufung "unsicher" ist vermutlich die Referenzierung der ungeschützten Site 'http://highslide.com/ in der JS Steuerdatei "highslide.js".
Damit wird versucht, eine potentiell unsichere http Seite in einer SSL geschützten https Seite anzuzeigen. Das darf im Sinne der "Same-Origin-Policy" natürlich nicht sein.

Wenn Du auf dem Webserver im Verzeichnis "index_htm_files" in der JS Steuerdatei "highslide.js" den Eintrag

creditsHref : 'http://highslide.com/',

entfernst*, wird die Slideshow vermutlich wieder angezeigt...

Probier's mal

--------------------------
* Bei jedem neuen Upload Deiner Site wird der WD die "reparierte" JS Datei mit der Originalversion überschreiben und damit den Slideshow Fehler neu generieren.
Damit Du nicht nach jedem Upload die "Reparatur" neu vornehmen musst, kannst Du einmalig die reparierte JS Datei in das Hilfsverzeichnis Deines Projekts kopieren. Danach sorgt der WD dafür, dass die reparierte Datei korrekt auf dem Webserver abgelegt wird. 😉

BERO, danke für den Hinweis.

habe in der highslide.js den Eintrag nicht gefunden. Dort steht nur

creditsText:"Powered by <i>Highslide JS</i>",

    creditsTitle:"Auf die Highslide JS Homepage gehen",

Allerdings ist die Datei noch von 2017 ... Soll ich mal die gesamte Site neu hochladen ?

[...] habe in der highslide.js den Eintrag nicht gefunden. [...]

Na, dann such' nochmal... 😁

[...] Mein Counter läuft übrigens auch nur noch unter Windows, vielleicht ist das dieselbe Ursache? [...]

Richtig!

OK, mein Fehler, hatte den autom. Zeilenumbruch nicht aktiv, sodass ich nur die eine Zeile Text sah ....

Wenn ich beim Löschen keinen Fehler gemacht habe, war dieser Befehl wohl doch nicht die Ursache, dass die Slideshow nicht angezeigt wird. Es hat sich nichts geändert, weder bei Android noch bei iOS.

In welcher Datei finde ich den Eintrag mit dem Counter ? Ich bin schon 3 Jahre raus aus dem Thema ....Und wenn ich die Datei habe, soll ich dann einfach http mit https ersetzen ?

[...] Es hat sich nichts geändert, weder bei Android noch bei iOS. [...]

OK, die Ursache ist dennoch sehr wahrscheinlich die nicht korrekt umgesetzte "Same-Origin-Policy".
Wo genau der "Hase im Pfeffer" liegt, kann ich Dir so auf die Schnelle aber nicht sagen...

Du findest im gesamten HTML Text und in den referenzierten JS/CSS Dateien noch viele weitere, verdächtige http Referenzen, z. B. in der "index_htm_files/jquery.js" und in der "index_htm_files/roe.js".
Außerdem wird noch in der "//www.sixer4u.de/mein m635.htm", in Zeile 34 auf eine JS Datei referenziert, die auf einer ungeschützten Domain liegt...

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>

[...] In welcher Datei finde ich den Eintrag mit dem Counter ? [...]

den findest Du auf der Seite "//www.sixer4u.de/" , in Zeile 67

<a id="1480960471" href="http://www.counter.de/">counter.de</a><script type="text/javascript" language="JavaScript" src="http://www.counter-go.de/counter_js.php?account=1480960471"></script><noscript><a href="http://www.counter-go.de/" target="_blank"><img border=0 src="http://www.counter-go.de/counter.php?account=1480960471"/></a></noscript>

[...] soll ich dann einfach http mit https ersetzen ? [...]

Für den Counter- und für die o. a. JQuery Dateien wird das funktionieren, weil die Anbieter ihre Sites schon entsprechend umgebaut haben, für die highslide Dateien geht's wahrscheinlich nicht so einfach 😎
Hier noch ein paar Infos, die der Feuerfuchs dazu beigesteuert hat:

Wenn Du die nötigen Anpassungen direkt im HTML Code der Seiten vornimmst, wird der WD beim nächsten Upload alle Änderungen rückgängig machen!
Du bist also besser beraten, wenn Du direkt im WD Editor die nötigen Anpassungen vornimmst und anschließend einen Upload startest. 🤓

Danke BERO für deine Antwort.

Der Counter funktioniert jetzt wieder. Die Counter-Verweise habe ich auf HTTPS geändert (nachdem ich die Zeilen 67ff  in der INDEX.HTM endlich gefunden habe  - was man so alles vergisst in 3-4 Jahren)

Parallel habe ich direkt im Programm den Eintrag auch geändert, sodass beim nächsten Hochladen nichts überschrieben wird.

Mit der Slideshow: Da von der referenzierten Website Highslide nicht mehr unterstützt wird, frage ich mich, ob es nicht gleich besser und einfacher wäre, ein anderes Widget einzusetzen. Das derzeitige habe ich ja aus der Design-Galerie des WD 11.

Wie kann ich vor der Installation eines anderen Widgets erkennen, ob dieses auf HTTPS referenziert ? Soweit ich sehe, sind die Widgets aus der Design-Galerie alle auf XARA lizenziert, aber mehr erfährt man vorher nicht.

Danke nochmal.

[...] Da von der referenzierten Website Highslide nicht mehr unterstützt wird, frage ich mich, ob es nicht gleich besser und einfacher wäre, ein anderes Widget einzusetzen. [...]

Ich habe mir die Einbau Methode der Slideshow noch mal angehsehen. Hier ist wohl noch eine einfache Reparatur möglich.

Wenn Du auf der Seite "mein m635.htm" in Zeile 34 den Verweis auf die Google APIS vom http Protokoll auf das https Protokoll änderst, dann sollte die vorhandene Slideshow laufen.

Das Ergebnis der online gestellten, geänderten Version kannst Du hier sehen (klick) 😉

[...] Wie kann ich vor der Installation eines anderen Widgets erkennen, ob dieses auf HTTPS referenziert ? [...]

Vor der Installation ist das i. d. R. nur möglich, wenn Du den benutzten Script-/Programmiercode analysierst. Aber in Deinem Fall ist das dazu nötige "Informatik Studium" nicht nötig (s. o.) 😀

BTW
Der "alte" WD hat noch ein paar Scriptcodes im Gepäck, die zumindest veraltet- z. T. auch fehlerhaft sind.
Hier geht's um die JQuery Bibliothek "jquery-1.9.1.js", die auf ein falsches Mapping verweist, und die Datei "highslide.js", in der ein Syntaxfehler enthalten ist.
Eine aktuellere Version kannst Du hier herunterladen (klick).

Auch die Bibliothek kannst Du leicht gegen eine aktuellere Version eintauschen, die Du frei im WWW herunterladen kannst. Das kann z. B. die Version "jquery-1.11.3.js" oder eine noch aktuellere sein.
Du musst in beiden Fällen natürlich die Dateien im Verzeichnis "index_htm_files" (besser noch im Hilfsverzeichnis) ablegen und für die JQuery Bibliothek auch die Quelleninfo auf den Seiten ändern, auf denen sie benutzt wird.
Bei Dir ist das auf der Seite "index.htm" in Zeile 27 der Fall.

Das soll's erst mal sein, mehr "Hausaufgaben" gibt's heute nicht... 🤓

OK, Punkt 1 war ja einfach, mein Schwierigkeitsgrad😉 Läuft prima, danke !

Auch die anderen Dateien hab ich direkt erneuert, auch in die Hilfsdatei gelegt. Lade ich noch neu hoch ….

Frage: Muss/soll ich die alten Dateien aus der Hilfsdatei löschen ?

Dann ist mir noch aufgefallen, dass das folgende Script im Head sitzt. Muss ich da was ändern ?

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>

<script type="text/javascript">// <![CDATA[

  jQuery.noConflict();

function scroller(anchor, delay) {

jQuery('html,body').animate({scrollTop: jQuery(anchor).offset().top}, delay);

};

// ]]>

</script>

[...] Muss/soll ich die alten Dateien aus der Hilfsdatei löschen [...]

Dateien, die nicht mehr benötigt werden, solltest Du in jedem Fall aus dem Hilfsverzeichnis löschen.
Das Löschen ist aber überflüssig, wenn Du Dateien mit identischem Namen durch neuere Versionen ersetzt. In dem Fall wird die alte Datei ja automatisch überschrieben. 😉

[...] Dann ist mir noch aufgefallen, dass das folgende Script im Head sitzt. Muss ich da was ändern ? [...]

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>

Jein. 😇

Ich hatte den Script Eintrag natürlich ebenfalls gesehen, ihn aber bewusst ignoriert, weil die JS Funktion "scroller(anchor, delay)", für deren Aktivität die "min Bibliothek" vorgesehen war, auf Deinen Sites scheinbar an keiner Stelle benutzt wird...
Du könntest also problemlos auf allen Seiten die u.a. JS Einträge löschen

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js">
</script>
<script type="text/javascript">// <![CDATA[
  jQuery.noConflict();function scroller(anchor, delay) {
jQuery('html,body').animate({scrollTop: jQuery(anchor).offset().top}, delay);
};
// ]]>
</script>

oder Du änderst die Protokoll Angabe auch hier (auf allen Seiten) in https

Wie gesagt, nötig ist das nicht. Du vermeidest allenfalls eine Fehlermeldung, die aber die korrekte Anzeige Deiner Sites nicht weiter stört.

Edit: 21:15 h
sorry, ich sehe gerade, dass Du die Funktion "scroller(anchor, delay)" doch auf einigen Seiten benutzt, z. B. auf der Seite "updates.htm".
Lass das dazu gehörende Script also drin und ändere die Protokoll Angabe von http auf https, wie weiter oben beschrieben...

Gut, BeRo, das mach ich dann aber am besten gleich im WD, oder?  

Wenn ich schon auf jede der ca. 60 Seiten muss, würde ich dann gleich alle erforderlichen Änderungen machen.

Habe mal am Beispiel einer Seite die http und jquery_Einträge aufgelistet, welche so wohl auf allen Seiten identisch sind. Welche Einträge kann bzw. muss ich denn da alles ändern ?  

Im Hilfsverzeichnis habe ich derzeit folgende Dateien liegen. Wenn ich die neue Query-Datei in den alten Namen umbenenne, kann ich mir dann die Änderung der Einträge sparen ?

Danke schon mal im Voraus !

[...] Welche Einträge kann bzw. muss ich denn da alles ändern ?  [...[]

Auf allen Seiten alle Einträge die mit "hhtp:" beginnen. Die änderst Du in "https:"
Natürlich nicht die Einträge, die ein "http" ohne folgenden Doppelpunkt haben!

Und auf allen Seiten die Quellangaben "src= xxxxx/jquery-1.9.1.js". Die änderst Du in z. B. "src= xxxxx/jquery-3.5.1.js".
Andere Referenzen von Jquery Dateien müssen nicht geändert werden, weil die z. B. direkt den Inhalt des Verzeichnisses "index_htm_files" benutzen.

[...] Wenn ich die neue Query-Datei in den alten Namen umbenenne, kann ich mir dann die Änderung der Einträge sparen ? [...]

Ja, sicher. Damit verschleierst Du zwar die Identität der so manipulierten Dateien, aber das wird dem WD egal sein. 😉
In dem Fall musst Du nicht mehr beide JQuery Bibliotheken im Hilfsverzeichnis ablegen, dann genügt es, wenn Du die "jquery-1.9.1.js" löschst und die "jquery-3.5.1.js" umbenennst in "jquery-1.9.1.js".
In der Seite "index.htm" hast Du in Zeile 27 schon die neue "jquery-3.5.1.js" als Quelle eingetragen. Den Eintrag müsstet Du dann also wieder auf "jquery-1.9.1.js" ändern...

OK, die jquery-Sache ist gelaufen durch umbenennen.

Die Http: Änderungen wollte ich ja eigentlich im WD an der Quelle machen, damit ich bei neuem Hochladen nicht wieder alle 60 Dateien anfassen muss.

Die im Head der Website sitzende Http: ist klar, aber wo finde ich die http:/www.w3.org im WD?

Auch die Änderung der http: für die Slideshow (wie oben beschrieben), kann ich die dauerhaft im WD ändern oder ist das dieselbe wie aus dem Head der Website ?

[...] Die im Head der Website sitzende Http: ist klar, aber wo finde ich die http:/www.w3.org im WD? [...]

Die Doctype Infos werden vom WD beim Export/Upload hinzugefügt. In den älteren WD Versionen sieht das so aus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Wenn Du eine der undokumentierten Funktionen des WD benutzt, kannst Du eine eigene "Kreation" beliebigen HTML Codes an den Anfang der Seite(n) setzen.
Dazu erstellst Du einen Platzhalter in der Seite und gibst ihm den Namen "<html>". Dann füllst Du den HTML Body des Platzhalters mit dem Code, den Du später am Anfang der Seite sehen willst.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="https://www.w3.org/1999/xhtml">

Das wa's dann auch schon.
Beim späteren Export/Upload wird der Doctype dann zwar 2x eingetragen (neue und alte Version), der aufrufende Browser orientiert sich aber immer an der zuerst gelesenen Version und das ist die neue, mit der https Protokollinfo 😇

Aber, Du musst diesen Klimmzug nicht machen. Die aktuellen Browser nehmen die Doctype Info nicht "ernst" und ignorieren daher auch die "Same-Origin-Policy". Es wird also keine Fehlermeldung geben, wenn Du die w3.org Verlinkung nicht änderst.

[...] die Änderung der http: für die Slideshow (wie oben beschrieben), kann ich die dauerhaft im WD ändern [...]

Ja, den "Grundstein" dazu hast Du schon gelegt, als Du die Datei "highslide.js" in das Hilfsverzeichnis gelegt hast.
In der Datei löschst Du die Zeilen 41 und 42 oder Du kommentierst sie aus, indem Du 2 Slashes davor eintippst

Na dann, viel Erfolg 👍

Habe nach dem Veröffentlichen der Seite das Problem, dass sich die Popup-Bilder nicht mehr schließen lassen, es fehlt auch der Rahmen mit der Beschriftung und das Schließen-Kreuz (unabhängig davon hat sich auf einigen Seiten die Schriftgröße verändert bzw. ganze Worte fehlen .....erwähne das nur der Vollständigkeit halber, vielleicht hängt alles zusammen)

Also, habe dann testweise lokal in der Hilfsdatei die angepasste highslide.js mit der alten Version getauscht - und es geht wieder mit den Popup-Bildern - und die Slideshow geht auch, obwohl in der alten highslide.js noch die Http-Links drin sind .....

Ich versteh das nicht mehr !

Beim neuen Veröffentlichen habe ich nur die Datein überschreiben lassen, welche sich verändert haben, es sind jetzt noch einige Dateien mit altem Datum drin , eine Fehlerursache ?