Am Host die Subdomain erstellen …

Hier ist nun der Arbeitsablauf von wegen am Host der Subdomain bis kurz nach der Installation von WordPress.

1. Am Beginn ist am Host die Subdomain zu erstellen. Hier des Beitrags der Namensgebung m.domain.net. So ist dem Namen hier auch die neue Datenbank.
   • Aufgepasst! – ob der Erstellung der neuen Website im Bereich WP-Multisite, dann ist keine Datenbank anzulegen. Im nächst ist nach der Festlegung des Themes folgend der Pkt. 5 + 6 relevant. Für hin mit WP-Multisite siehe auch hier im Tab 7.
2. Nun weiter separate Instanz. Des FTP-Clients ist gleichen Zugang wie die Haupt-Domain. Also eigens FTP-Zugang braucht es nicht. Dort dem öffentlichen Bereich ist dann ein 'Neuer Ordner' zu erstellen und des bspw in mobil-wordpress zu benennen.
3. Die neueste WordPress-Version auf den Comp. Downloaden und zip-Datei entpacken. Dann den Ordner wordpress zum Server hochladen. Und von dort nun nur den Inhalt von Ordner wordpress in den selbst erstellten Ordner mobil-wordpress verschieben.
   • Hinweis! Den Ordner wordpress hochladen und umbenennen funktionierte hier nicht.
4. WordPress ist somit zu installieren.
5. Nun der Subdomain wird ja der Content der Hauptseite, folglich ist das Doppelcontent. Daher ist die Website https://m.domain.net den Suchmaschinen auszuschließen. Siehe Einstellungen → Lesen, 'Sichtbarkeit für Suchmaschinen'.
   • Indes dann dem Tab 3: Den Suchmaschinen die beiden Websites mitteilen.
6. Dann der neuen Website https://m.mobil.net die Links unter Einstellungen → 'Permalinks' anpassen. Gebräuchlich wie zu empfehlen ist meist das mit 'Beitragsname'.

Der Dateien Ex- und Import

Dem Thema ist sehr mit Aufmerksamkeit zu folgen und das reibungslos vonstattengeht.

1. Der Export. Der Hauptseite domain.net unter 'Werkzeuge' → 'Daten exportieren' …

   

2. Also 'Export-Datei herunterladen'. Am gescheitsten 'Alle Inhalte'. Dies 'Alle Inhalte' ist auch der Suchmaschinen zum 1:1 Content ein Muss. So nach dem Upload von 'Alle' ist die XML-Datei am Comp.
3. Der Import. Somit kann der Import dieser Datei erfolgen. Also der Website Subdomains m.domain.net unter Werkzeuge → 'Daten importieren'. Wenn das Plug-in noch nicht installiert ist, so ist das nun zu installieren.
   • Von wegen Medien und SVG ist darauf zu achten, dass der Zielseite auch so Plug-in wie 'Safe SVG' aktiviert ist.

     

     … und ist von dort weg auch auszuführen.

     

Tipps

Anderer Plug-in so zum Ex- / Import sind nicht so das als die der WP-Werkzeuge …

Und sollten zum Export dann so Inhalte dabei sein, die nicht zu gebrauchen sind, so möchte man auf den Nutzen kommen wie nur der Beiträge die Auswahl unter Status da ist auch wie 'Veröffentlichte' zu wählen usw. Hingegen ist das so mit 'Alle Inhalte', das noch mal gesagt! – ist g’schickt.

Denn allein dass die Navigationsmenüs dabei sind, ist das mit 'Alle Inhalte' zu bevorzugen. Die Anhänge gehören ebenso dazu. Danach eben, welches nicht zur Verwendung ist, ist zu löschen. Auch wenn dabei etwas Klick-Tun(ING) angesagt, ist das die bessere Methode. Im anders dann mit so Plug-ins wie 'Export WordPress Menus' kommt hernach auch nichts anderes heraus als noch mehr Durcheinander. Des Letztren mit Vorbehalt.

Ferner aus Gründen wie immer, wenn dann so Menü nicht so ist wie sein soll. Bspw war der Website WP-Multisite das Menü, außer dort der Kategorien nichts da … So ist dann anderes Plug-in im Namen Export Import Menus das Mittel der Wahl! – funktioniert so, dass nur das Menü zu Exportieren / Importieren ist. So Nacharbeit des Menüs kann aber auch angesagt sein, aber das resultiert aus Eingemachten, bspw wenn so Beitrag hernach mal auf Entwurf gesetzt wurde und aus dem Menü nicht entfernt wurde und so.

Haben sich indes so Ungereimtheiten eingeschlichen, dass gut ist die Beiträge der Hauptseite allein zu exportieren, dann bspw so:

Daten exportieren

Eia vor dem Import zur Subseite. Die Beiträge, welche dort schon der Subseite sind, die müssen vorher in den 'Papierkorb' und der Button 'Papierkorb leeren' ist anzuwenden! – sonst zeigt sich dem Import "Die Datei ist schon vorhanden". … So zur Vorbeugung von wurschteln.

4. Danach sind dann mit so Plug-in 'Better Search Replace' die URLs anzupassen. Und da ist nun Obacht zu geben! – denn die URLs sollen ja hier nur so der internen Links von Beiträgen / Seiten usw. angepasst sein. Dass nämlich die Dateien aus der Mediathek von der Hauptseite verlinkt bleiben.

Dazu nun Workflow die sichere Methode:

Die URLs anpassen

Vorerst ein Kommentar der ersten Reihe WP-Fachmann: Suchen & Ersetzen ersetzt immer alle URLs. Da Medien in der Datenbank auch als "Post" abgespeichert wie Seiten und Beiträge, sind diese auch betroffen. Mit der aktuellsten Version von WordPress benötigt man dafür aber kein Plugin mehr, WordPress macht das zum Großteil selbst – wenn du die URL unter Einstellungen > Permalinks festlegst. – Wichtig ist zu wissen, dass Suchen & Ersetzen Plugins, gerne mal Optionen anderer Plugins fehlinterpretieren, weshalb dann Optionen überschrieben sind. Da gibt es zum Teil Cookie-Banner Plugins, die alle Optionen verlieren und überall nur Zahlen drin stehen – statt bspw. "Akzeptieren" oder "Alle Cookies ablehnen".

Sehr gut zu wissen, so könnte man sich das im Folgenden hintanstellen. Bleibt nur noch mein Hinweis! – sind nämlich vielerlei so interne Links von einem zum anderen Beitrag, dann müssen diese in Flickarbeit angepasst werden … Also ist hier viel besser das so im Folgenden:

Die URLs anpassen
… mit so Plug-in 'Better Search Replace'

• Suchen nach: href="https://domain.net/
• Ersetzen durch: href="https://m.domain.net/

… Infolge wie hier, dass die Bilder von der Hauptseite abgerufen werden. So ist darauf acht zu geben, dass das href mit dabei ist. Denn sonst würden die Links Bilder, welche Medien auf der Hauptseite sind, auch umgestellt.

Die Links intern sind href="https://domain.net/ und die der Bilder mit src, also src="https://domain.net/. Infolge der Achtsamkeit ist der nächst Punkt 'Die URLs der Mediathek zurück der URL Haupt-Seite' hinfällig.

Aufpassen, dass nach / kein Leerzeichen ist.

… Nun laufen alle URLs gemäß der Domain m.domain.net.

Wenn so für im Nachhinein mal sein muss, wenn so inklusive der Medien umgestellt sind, die aber hier der Instanz gar nicht da sind. Folgend ob Instanz oder Multisite ist da egal.

Also und infolge nun das mit der Datei-URL von der Medien. Die URLs sind auf die vorhergehende zurückzustellen.

Die URLs der Mediathek zurück der URL Haupt-Seite

Suchen nach: https://m.domain.net/wp-content/uploads/
Ersetzen durch: https://domain.net/wp-content/uploads/

Somit sind der Subdomain m.domain.net die Bilder in den Beiträgen / Seiten von der Hauptseite domain.net visuell.

Die Pflege der beiden Websites

Die Methode hier, das bedingt nun Workflow und ist so ganz einfach, aber nicht ganz leicht.

Nun, der Website domain.net der Bearbeitung von Beitrag ist das dann auf m.domain.net zu übertragen. Dasjenige folgt auch in Erstellung eines neuen Beitrags. – von Kopie und Paste ist dann darauf zu achten, die internen Links auch gleich anzupassen.

Suchen und Ersetzen

Das Suchen und Ersetzen von Link geht nicht mit 'Advanced Editor Tools'. Da dies nur vom Editor 'Visuell' geht und so das HTML nicht dabei ist.

• Das geht hier dem Editor 'Text' und dann über die Wortsuche des Browsers – cmd+f für Mac, strg+f für Windows.
• Auch hier ist darauf zu achten der Zeichenfolge href="https://domain.net/.
• Der Wortsuche sind die Links farblich sehr gut hervorgehoben. Von Hand dann durch scrollen ist das der Reihe nach zu ändern.

Den Suchmaschinen
die beiden Websites mitteilen

Das Rundherum siehe das Bild:

HINWEIS: FOLGENDES IM SCROLLE STAMMT DER WEBSITE CONTENT-KING rel = "alternate" mobiles Attribut. DIE WEBSITE IST NICHT MEHR ONLINE UND SO WAR DER SEHR GUTE INHALT DER WAYBACKMACHYNE ZU FINDEN: https://web.archive.org/web/20220118221918/https://www.contentkingapp.com/academy/mobile-attribute/

UND HIER IST NOCHMALS EINE SICHERUNGSKOPIE

rel="alternate" mobiles Attribut

Wenn Sie separate mobile und Desktop-Websites haben, müssen Sie den Suchmaschinen die Beziehung zwischen diesen beiden klar machen, damit sie verstehen, welche Website ihren Benutzern angezeigt werden soll, und um Probleme mit doppelten Inhalten zu vermeiden .

Beachten Sie beim Implementieren dieses Attributs unbedingt die folgenden Best Practices:

• Bidirektionale Referenzen mit dem mobile-Attribut von Desktop zu Mobile und dem kanonischen Link von Mobile zu Desktop.
• Eins-zu-Eins-Beziehungen: Jede Desktop-Seite hat ein mobiles Gegenstück und umgekehrt.
• Vermeiden Sie Weiterleitungen: Verweisen Sie nur auf tatsächliche Seiten.
• Verwenden Sie absolute URLs einschließlich des Domänennamens und des Protokolls.

Inhalt folgend

• Was ist rel="alternate" mobile?
• Wann sollte ich das mobile Attribut verwenden?
• So implementieren Sie das mobile Attribut
• Best Practices für mobile Attribute
• Häufig gestellte Fragen zum mobilen Attribut
• Ressourcen

Was ist rel="alternate" mobile?

Wenn Leute von rel="alternate" mobile, rel="alternate" media tag oder rel="alternate" media attribute sprechen , beziehen sie sich auf diese Linkrelation:

<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/">

Der Einfachheit halber nennen wir es hier das mobile Attribut.

Diese Linkrelation wird verwendet, um Suchmaschinen eine Beziehung zwischen einer Desktop- und einer mobilen Website anzuzeigen. Wenn Sie eine separate Desktop- und mobile Website haben und sich um mobiles SEO kümmern, müssen Sie das mobile Attribut verwenden. Derzeit unterstützen nur Google und Yandex die Verwendung des mobilen Attributs.

Wann sollte ich das mobile Attribut verwenden?

Wenn ein beträchtlicher Prozentsatz Ihrer Besucher von mobilen Geräten kommt, kann es sinnvoll sein, ihre Erfahrung mit einer dedizierten mobilen Website zu optimieren. Beachten Sie, dass sich dies von einer „responsiven Website“ unterscheidet. Bei einer responsiven Website gibt es eine einzelne Website mit einem Layout, das sich an das Gerät anpasst, auf dem sie angezeigt wird, während es bei einer dedizierten mobilen Website eine vollständig separate Website mit eigener URL gibt.

In diesem Fall, wo Sie separate Desktop- und mobile Websites haben, möchten Sie, dass Suchmaschinen dem richtigen Benutzer die richtige Version der Website anzeigen. Wenn Benutzer auf einem Desktop Suchmaschinen verwenden und Ihre Website angezeigt wird, möchten Sie, dass sie auf Ihrer Desktop-Website landen. Wenn sie sich auf einem mobilen Gerät befinden, möchten Sie, dass Suchmaschinen Ihre mobile Website anzeigen.

Überprüfen Sie schnell, ob Ihr Link-rel-Attribut korrekt implementiert ist und sehen Sie, was mit ContentKing verbessert werden kann.

So implementieren Sie das mobile Attribut

Das mobile Attribut kann im HTML oder über die XML-Sitemap implementiert werden.

Implementierung in HTML

Auf der Desktop-Seite Verwenden Sie im HTML der Desktop-Seite die Link-Relation-Definition, um auf die mobile Version der Seite zu verweisen:

<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/">

Das bedeutet, dass die mobile Website bereitgestellt werden sollte, wenn die Breite des Geräts des Benutzers weniger als 640 Pixel beträgt.

Auf der mobilen Seite Zeigen Sie im HTML der mobilen Seite mit der kanonischen URL auf die Desktop-Version der Seite:

<link rel="canonical" href="http://www.example.com/">

Die kanonische URL dort zu haben, verhindert Duplicate Content. Es teilt Suchmaschinen mit, dass die Desktop-Seite indexiert werden soll .

Umsetzung durch XML-Sitemap

Google unterstützt auch die mobile Attributdefinition durch XML-Sitemaps.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <url>
        <loc>http://www.example.com/</loc>
        <xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/" />
    </url>
</urlset>

Bitte beachten Sie, dass die kanonische URL weiterhin auf der mobilen Seite vorhanden sein muss und auf die Desktop-Seite verweist.

Best Practices für mobile Attribute

Bidirektionale Referenzen

Damit Suchmaschinen die Beziehung zwischen der Desktop- und der mobilen Seite verstehen können, muss die Desktop-Seite das mobile Attribut haben und die mobile Seite die Beziehung mit der kanonischen URL „bestätigen“.

Eins-zu-eins-Beziehungen

Jede Desktop-Seite sollte nur ein mobiles Gegenstück haben und umgekehrt.

Vermeiden Sie Weiterleitungen

Vermeiden Sie rel=alternate mobile und rel=canonical Tags, die auf URLs verweisen, die wiederum auf andere Seiten weiterleiten. Für Suchmaschinen ist das verwirrend.

Verwenden Sie absolute URLs

Auch wenn dies nicht gegen die Spezifikation des Link-Tags verstößt, besteht allgemeiner Konsens darin, bei der Definition des mobilen Attributs keine relativen URLs zu verwenden. Relative URLs werden von Suchmaschinen eher falsch interpretiert. Die gleiche Best Practice gilt für andere Verwendungen des Link-Tags: kanonische URL , hreflangAttribut und Paginierungsattribute.

Testen Sie die mobile Freundlichkeit

Verwenden Sie das mobilfreundliche Tool von Google(öffnet in einem neuen Tab)um die mobile Freundlichkeit Ihrer Website zu testen.

Häufig gestellte Fragen zum mobilen Attribut

1. Warum ignorieren Suchmaschinen mein mobiles Attribut?
2. Ich habe eine responsive Website. Muss ich auch das mobile Attribut verwenden?
3. Ich stelle unterschiedliche Inhalte auf meinen Desktop- und mobilen Seiten bereit. Ist das ein Problem?

1. Warum ignorieren Suchmaschinen mein mobiles Attribut?

Das mobileAttribut ist eher ein Signal als eine Anweisung . Suchmaschinen sind nicht verpflichtet, Ihrer Definition des mobilen Attributs zu folgen, tun dies jedoch normalerweise.

2. Ich habe eine responsive Website. Muss ich auch das mobile Attribut verwenden?

Nein, wenn Sie eine responsive Website haben, müssen Sie das mobile Attribut nicht verwenden. Das mobileAttribut sollte nur verwendet werden, wenn Sie eine separate Desktop- und mobile Website mit unterschiedlichen URLs haben.

3. Ich stelle unterschiedliche Inhalte auf meinen Desktop- und mobilen Seiten bereit. Ist das ein Problem?

Suchmaschinen sind immer noch Desktop-orientiert, sodass Ihre Desktop-Website führend ist, wenn Suchmaschinen die Relevanz Ihrer Website für Suchanfragen bestimmen. Google hat jedoch angekündigt, dass sich dies irgendwann im Jahr 2018 für sie ändern wird: Ihre mobile Website wird führend sein. Suchmaschinen nennen dies einen „Mobile-First-Index“.

Entgegen der landläufigen Meinung wollen mobile Benutzer oft nicht weniger Inhalt und weniger Funktionen, daher ist es sinnvoll, ihnen einfach das Gleiche anzubieten, aber mit einer für Mobilgeräte optimierten Erfahrung.

Der Hauptseite Desktop

In der header.php im Abschnitt <head> </head>:

<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.domain.net/">

… und der Subdomain mobil

In der header.php:

<link rel="canonical" href="https://domain.net/">

Nachlese

Canonical Links: die 13 häufigsten Fehler
…  und sehr differenziert im Titel Kanonische URLs: Ein Leitfaden zu kanonischen Tags im Jahr 2021

Somit bleibt die Frage beiden Websites,
die Suchmaschinen einladen?

Es besteht keine absolute Gewissheit, dass Suchmaschinen immer exakt auf diese Tags reagieren. Es kann vorkommen, dass trotz der Verwendung der Tags beide Versionen einer Website in den Suchergebnissen erscheinen. Dies kann auf verschiedene Faktoren wie die Algorithmen der Suchmaschinen oder Fehler bei der Implementierung der Tags zurückzuführen sein.

Der Hauptseite des Codes rel="alternate" und die Spielart mobil von rel="canonical".

Die Annahme

• Die Annahme ist, sind die beiden Websites den Suchmaschinen offen, so folgen der Suche von Desktop oder Mobilgerät entweder von domain.net oder m.domain.net. Dieweil ist dem TEST, dass beide Websites den Suchergebnissen da sind.

Der Test

Die Suchmaschinen wurden auch für die zweite Website m.domain.net eingeladen. Somit waren bald so zehn Artikel zu sehen. Worauf die Suchmaschinen wieder ausgeladen wurden. In kurzer Zeit kamen so noch mal zehn Artikel hinzu … Dem TEST zu den Suchergebnissen nun, so sind da beide Websites in den Suchergebnissen. So bleibt der Schluss, dass das nicht so funkt, wie es konform.

Somit aber der Subdomain nun der Ausschluss von Suchmaschinen ist, so hat das rel="alternate" und rel="canonical" keinen Zweck. Hingegen den Suchergebnissen von so zwei identische Websites ist das Pflicht! Sodass dies nicht als Doppelcontent und so des Rankings abgestraft wird. Aber so gleich wie verzichtbar sind diese Codes, wenn der Subdomain die Einladung der Suchmaschinen ausgeschlossen ist. Im weiter so viel gescheiter? Denn von Ergebnissen der Suche, die zwei Websites untereinander nicht konform ist. Oder so doch?

Das Fazit zur Frage

Das mit den doppelten Ergebnissen mag für den Surfer nicht das Beste sein. Daher bleibt hier die Subdomain des Weitern den Suchmaschinen ausgeschlossen. – mal sehen, wie craw-lings Artikel aus der Indexierung entfernt werden.

• So Nachlese von Google Search Central im Titel Duplizierte URLs zusammenfassen.

Weiter ist da sich dem Thema der Begriffe zu befassen als da "User-Agent-String-Erkennung Javascript wordpress".

Der Website zur anderen,
so mit Link zu Link

Es ist nun sehr schön, wenn von Besuch der domain.net und von dort im Wechsel zu m.domain.net auf denselben Beitrag weist und vs.

Der Shortcode des Links
von der Hauptseite zur Subdomain

functions.php

/* Shortcode Link zu Link */
add_shortcode( 'm.domain_url', function() {
   $slug = get_post_field( 'post_name', get_post() );
   return $url = 'https://m.domain.net/' . $slug;
});

^{Pr. WP-Freund}

Das HTML:

<a href="[m.domain_url]">Text Text Text</a>

… Vs von der Subdomain zur Hauptseite

functions.php

/* Shortcode Link zu Link */
add_shortcode( 'domain_url', function() {
   $slug = get_post_field( 'post_name', get_post() );
   return $url = 'https://domain.net/' . $slug;
});

^{Pr. WP-Freund}

Das HTML:

<a href="[m.domain_url]">Text Text Text</a>

Das Beispiel:

<p style="text-align: center; font-size: 20px;"><a href="[m.domain_url]" rel="noopener"><b>wegerl.at! – gleich m.wegerl.at</b></a></p>

wegerl.at! – gleich m.wegerl.at

Bemerkung in Anwendung des Shortcode

Der Website ist unter Einstellungen › Lesen 'Eine statische Seite'.

In Konfiguration 'Eine statische Seite' der 'Beitragsseite' folgt im anklicke des Shortcode-Link ∴nicht∴ die 'Beitragsseite', sondern die ’statische Seite' (Homepage). – das geht so aus dem Core WP hervor.

Weiter war ein Missfallen mit geliebten Ditty News Ticker. Gleich dem Obigen mit der Beitragsseite da leitete das nicht auf die Homepage, sondern lieferte einen Fehler.

Das Widget 'Individuelles HTML'

Des Letztren möchte ich noch sagen, dass der Shortcode-Link so im Widget 'Individuelles HTML‘ gehapert hat. Da ist nämlich gar nichts gegangen. Mit Widget 'Individuelles HTML‘ hat es ganz anderen Zusammenhängen immer wieder mal da und dort gehapert. Im 'Text' Widget ist wie immer okay!

Tipps zum Responsive

Im Folgenden ist zum Erkennen, wenn sich so Fragezeichen stellt.

… das der Responsive hapert?

Da hier ist erst mal das zu sehen wie die Website die Ansicht für Mobilgerät. So ist die Website responsive.

Anders wenn so CSS nicht passt

Das hier, welches dem TEST nach sehr unschön ist.

… Als dass stellt es sich nicht so richtig auf responsive. Ebenda ist da der Website so unpassendes CSS dabei.

Beispiele

Das beim Kommentar im Theme comments.php. So war des Bilds der Ausrichtung Margin links. Das ist so nicht hinzubekommen, dass responsiv. Nun allein mit center und Margin für oben oder unten dem Smiley gut ist.

<img class="aligncenter" style="margin-bottom: -12px;" src="https://smilies.4-user.de/include/Denken/smilie_denk_58.gif" alt="" width="auto" height="auto" border="0" /><p style="text-align: center; margin-bottom: -25px;"><span style="font-size: 12px;">//Silence is golden.</span></p>

Oder so Individuelles Feld (anklicke öffnet neuem Tab). So der Machart ist ja sehr empfohlen, die Bilder immer mit width und height auszuzeichnen und ist responsiv, soweit das im Content- und Widget-Bereich. So nun aber ein Bild in 'Individuelles Feld' ist mit width="auto" height="auto" auszuzeichnen … Ausnahmen bestätigen eben die Regel.

Weiter als Beispiel mit ↔ Overflow scroll gradient (anklicke öffnet neuem Tab). Das ist hier im Content hin und wieder in Anwendung. Das ist der Responsive wider, wenn so fixe Breite ist. Der fixen Breite mit auto ist das dann passend.

Die Ausführung von mobil mit WP-Multisite

Der Spielart ist hier das Theme für die Subdomain gleich wie das der Hauptseite. So Beispiel ist dann hier im Anschluss des Beitrags.

Erst mal

• … ist ebendies Theme zu definieren.
• Nun folgend ist da der Hauptseite schon so Childs-Theme. Im Falle des Bedarfs für die neue Website ist auch ein Child-Theme separat anzulegen.
• Am besten so folgend dem Titel Childs-Theme erstellen. Da ist dann aber nur mehr auf andere Namensgebung als dem Childs-Parent-Theme zu achten.

Das mit den URLs anpassen, s. von Tab 2

Bei WP-Multisites der Hauptseite ist darauf zu achten, die Tabellen auszuwählen, welche da relevant sind.

• Der Hauptseite sind nämlich so bspw Tabellen wp_,  wp_2_,  wp_3_.

Nebenbei dann das, dass man der Anpassung am Dashboard ist, welcher Website der URLs Änderung sein soll. Denn da hat man die Kontrolle von Adresszeile und so sind alle Tabellen auswählen und die Durchführung ist zu starten. Noch mal gesagt, von der Hauptseite ausgehend ist aber darauf zu achten, dass welche Tabellen auszuwählen sind.

Multisite synchronisieren?

So Plug-ins speziell für den Bedarf die Multisite zu synchronisieren.

U. a. da hatte ich das Plug-in 'WordPress Multisite Content Copier/Updater' im TEST. Das hat mir hier nicht funktioniert* . Schade, denn grad für so was wie diesem Beispiel das ein Ideal wäre. Andere Plug-ins, sind sehr für den kommerziellen Gebrauch. Somit ist das hier zu viel des Guten.

*Leute, so der Recherche, da zerbricht sich unsereins nicht den Kopf, denn so was kann möglicherweise nur funktionieren, wenn das Plug-in vorab der Erstellung so Multisite installiert ist … und so-so weiter. – im Netz ist im Heute sehr darauf zu achten, wie aktuell so Beiträge sind.

Nachlese WP-Multisite

… mit dabei ist hier scrolle

Mein Einblick

Erst mal vielen Dank dem Autor zur Stellungnahme.

Diese Zeilen nun möchte ich erst mal zum Theme Multisite in Überlegung stellen. Doch kann für sich des Workflows von so Websites wie hier auf Wegerl das recht performant sein. Auch wenn von mehr Websites des so Contents. Man siehe obigen Vergleichswert von Spiele-Portale und so. So bleibt der Multisiteerkenntnis von ab Entwicklung ist das nun auch für den sportiven Anwender … Nämlich von wegen so Dinge entwickelt wurde, dann auch für die normale Anwendung von Erfolg ist. Man denke da nur so an die Entwicklung des Internets.

Weiter so Pro-Meinungen, sind im Netz mit sehr guten Ausführung zur WP-Multisite.

Das Zitat bleibt: "Multisites können der Performanz wider werden", d. h. von wegen Websites, die sehr von voluminös.

Und wie performant

… das so Websites wie hier? Siehe weiter der Tabelle. Da geht es jeweilig derselben Website.

Static Website mit WordPress?

Weiter ergibt sich die Fragestellung, ob WordPress wenn möglich als sogenannte Static Website ausgeliefert wird. Mithin des Plug-ins Simply Static ist das so weit machbar. – der Performanz in Hinsicht Ladezeit ist das im Heute nicht mehr das. Und von so manches an mehr hat das dann nicht mehr mit WordPress zu tun.