Häufige Fragen zu Websites, internen Apps, SEO und KI

Nicht jede ältere Website muss neu gebaut werden. Ein Relaunch ist sinnvoll, wenn mehrere grundlegende Probleme zusammenkommen: veraltete Technik, schlechte mobile Nutzung, unklare Inhalte, Sicherheitsrisiken, langsame Seiten oder eine Struktur, die nicht mehr zum Unternehmen passt. Ist die Basis gesund und die Website bereits sichtbar, kann eine gezielte Website-Optimierung nach technischem Audit wirtschaftlicher sein.

Bei einem Redesign bleiben Technik, Inhalte und URLs weitgehend bestehen; vor allem Gestaltung und Komponenten ändern sich. Ein Relaunch kann zusätzlich Informationsarchitektur, CMS, Templates, Inhalte, Tracking, Integrationen und URL-Struktur verändern. Je mehr Ebenen gleichzeitig geändert werden, desto wichtiger sind Migration, Tests und ein klarer Rollback-Plan.

Ja. Häufige Ursachen sind gelöschte Inhalte, geänderte URLs ohne passende Weiterleitungen, verlorene Metadaten, fehlerhafte Canonicals, kaputte interne Links oder eine versehentlich übernommene noindex-Einstellung. Deshalb behandle ich einen Website-Relaunch als Design-, Entwicklungs- und SEO-Migrationsprojekt.

Relevante URLs mit Rankings, Backlinks oder Traffic sollten erhalten oder per permanenter 301-Weiterleitung auf den fachlich passenden neuen Inhalt geführt werden. Dafür wird vor dem Launch eine URL-Zuordnung erstellt, getestet und nach dem Go-live überwacht. Alle alten Seiten pauschal auf die Startseite umzuleiten ist keine saubere Migrationsstrategie.

Nur wenn es dafür einen klaren geschäftlichen oder technischen Grund gibt. Jede zusätzliche Änderung vergrößert die Zahl möglicher Fehlerquellen und erschwert die Ursachenanalyse. Wenn ein Domainwechsel notwendig ist, werden Weiterleitungen, Search Console, Sitemaps, interne Links, E-Mail-DNS und externe Profile als eigener Migrationsstrang geplant.

Normalerweise bleibt die bestehende Website erreichbar, während die neue Version in einer getrennten Umgebung entsteht. Der eigentliche Go-live wird vorbereitet, getestet und möglichst kurz gehalten. E-Mail ist technisch ein eigener Dienst; bei DNS- oder Hostingwechseln müssen MX-, SPF-, DKIM- und weitere Einträge bewusst übernommen werden, damit keine Nachrichten verloren gehen.

Ein fokussierter Neuaufbau kann in wenigen Wochen umgesetzt werden. Für einen strategischen KMU-Relaunch sind häufig acht bis sechzehn Wochen realistisch; größere, mehrsprachige oder integrierte Systeme benötigen länger. Texte, Fotos, interne Freigaben und nachträgliche Scope-Änderungen beeinflussen den Zeitplan meist stärker als erwartet.

Vor dem Relaunch werden Ausgangswerte dokumentiert: qualifizierte Anfragen, organische Klicks, wichtige Rankings, Conversion-Rate, Formularabschlüsse, Core Web Vitals und Indexierungsfehler. Nach dem Go-live werden dieselben Messpunkte, wichtige Nutzerwege und technische Signale kontrolliert. Ein professioneller Relaunch endet deshalb nicht unmittelbar nach der Umschaltung.

Wenn ein wiederkehrender Ablauf geschäftlich wichtig ist und dauerhaft Zeit durch doppelte Eingaben, Rückfragen, fehlende Übersicht oder unverbundene Programme verliert. Eine interne App für KMU lohnt sich nicht wegen möglichst vieler Funktionen, sondern wenn ein klarer Engpass messbar kleiner wird.

Wenn mehrere Personen dieselben Daten brauchen, Versionen auseinanderlaufen, Eingaben mobil erfolgen, Berechtigungen fehlen oder ein Fehler direkte Folgen für Auftrag, Abrechnung oder Kundenservice hat. Für persönliche Kalkulationen und selten genutzte Listen bleibt Excel oft die bessere Lösung.

Standardsoftware ist meist günstiger und schneller startklar, wenn sie den Kernprozess gut abdeckt. Individualsoftware wird interessant, wenn ein wichtiger eigener Ablauf mit Standardprodukten nur durch dauerhafte Workarounds, doppelte Pflege oder viele Zusatztools funktioniert. Häufig ist die beste Lösung eine schlanke individuelle Oberfläche, die vorhandene Systeme verbindet.

Eine klar abgegrenzte erste Web-App kann im mittleren vierstelligen Bereich beginnen. Mehrere Benutzerrollen, komplexe Schnittstellen, Offline-Nutzung, Datenmigration oder umfangreiche Geschäftsregeln führen meist in einen fünfstelligen Projektumfang. Vergleichbar werden Angebote erst durch einen konkreten ersten Ablauf und klare Abnahmekriterien.

Für viele interne Prozesse reicht eine responsive Web-App, die im Browser auf Computer, Smartphone und Tablet läuft. Das spart getrennte App-Store-Veröffentlichungen und mehrere Codebasen. Native Apps sind sinnvoll, wenn Gerätefunktionen, zuverlässige Offline-Nutzung oder besondere Leistungsanforderungen sie rechtfertigen.

Oft ja, wenn das jeweilige System eine geeignete API oder einen verlässlichen Import und Export bereitstellt. Vor der Umsetzung müssen verfügbare Daten, Rechte, technische Limits, Kosten und Fehlerfälle geprüft werden. Eine Schnittstelle sollte doppelte Eingaben reduzieren, nicht nur Daten unkontrolliert kopieren.

Ja, nachdem Tabellen, Formate, Dubletten, Pflichtfelder und Datenqualität geprüft wurden. Wichtig ist außerdem, Regeln zu dokumentieren, die heute nur einzelne Personen kennen. Erst dann lässt sich entscheiden, was automatisch migriert, bereinigt oder bewusst nicht übernommen wird.

Ja, wenn ein häufiger Ablauf viel Zeit kostet, Fehler verursacht oder Umsatz verzögert. Bei wenigen Rechnungen, Kontakten oder Aufgaben ist Standardsoftware meist wirtschaftlicher. Für EPU sollte eine erste Version besonders klein bleiben und einen klar berechenbaren Nutzen haben.

Mögliche Ursachen sind eine neue oder noch nicht indexierte Domain, technische Sperren, schwache oder unklare Inhalte, fehlende interne Links, starke Konkurrenz oder eine Suchanfrage, zu der die Seite nicht passt. Zuerst werden Indexierung und Search Console geprüft, danach Inhalt, Suchintention, lokale Signale und technische Qualität. Eine pauschale „SEO-Einstellung“ löst diese unterschiedlichen Probleme nicht.

Meist nicht allein. Für lokale Suchanfragen sind ein vollständig gepflegtes Google Business Profile, konsistente Unternehmensdaten, passende Leistungs- und Standortinformationen, Bewertungen und eine technisch saubere Website wichtige Bausteine. Website und Unternehmensprofil sollten sich in Namen, Adresse, Leistungen und Kontaktinformationen nicht widersprechen.

Nicht unbedingt. Häufig liegen die Ursachen bei unpassenden Suchbegriffen, einer unklaren Positionierung, fehlendem Vertrauen, schwachen Handlungsaufforderungen, Formularproblemen oder nicht gemessenen Conversions. 2.000 passende Besucher mit klarer Nutzerführung können wirtschaftlich wertvoller sein als 10.000 unpassende – SEO und Conversion müssen gemeinsam betrachtet werden.

Technische Grundlagen, Informationsarchitektur und eine saubere Migration können projektbezogen umgesetzt werden. Suchnachfrage, Wettbewerb, Inhalte und das eigene Angebot verändern sich jedoch laufend. Nicht jedes Unternehmen braucht einen großen monatlichen SEO-Vertrag, aber relevante Seiten, Suchdaten und technische Fehler sollten regelmäßig überprüft werden.

Nein, seriös nicht. Rankings hängen von Suchintention, Wettbewerb, Standort, Qualität, Aktualität und Googles Systemen ab; diese kontrolliert kein Dienstleister. Vereinbaren lassen sich konkrete Arbeit, technische Standards, Inhalte, Messpunkte und transparente Berichte – aber keine dauerhafte Position, die einem Anbieter nicht gehört.

Technische Fehlerbehebungen können schnell messbar werden, neue Inhalte und stärkere Rankings brauchen häufig Wochen oder Monate. Nach einer URL-Migration sind vorübergehende Schwankungen normal; kleine bis mittlere Websites werden oft innerhalb einiger Wochen weitgehend neu verarbeitet, größere Websites benötigen länger. Entscheidend sind saubere Weiterleitungen, Sitemaps, Crawlbarkeit und laufendes Monitoring.

Ja. Für Prototypen, Landingpages und kleine Websites kann KI Design, Texte und Code sehr schnell erzeugen. Die wichtigere Frage ist, wer sicherstellt, dass das Ergebnis in sechs oder zwölf Monaten noch sicher, schnell, wartbar, auffindbar und erweiterbar ist.

Weil Code nur ein Teil des Projekts ist. KI übernimmt nicht automatisch Geschäftsziele, Informationsarchitektur, bestehende Rankings, Migration, Analytics, Datenschutz, Barrierefreiheit, Integrationen, Security, QA und Betrieb. Wo KI Arbeit spart, sollte diese Effizienz den Preis reduzieren oder mehr Zeit für Qualität und Tests schaffen – nicht künstlich ignoriert werden.

Nicht automatisch. Entscheidend sind technische Zugänglichkeit, Genauigkeit, Struktur, Performance und echter Nutzen – nicht, ob ein Entwurf mit KI entstanden ist. Schwach sind massenhaft generische Inhalte ohne eigene Erfahrung; stark sind reale Projekte, Fachwissen, Messwerte, Prozesse, Entscheidungen und nachvollziehbare Autoren.

Nein. Crawlbare Seiten, klare Informationsarchitektur, hilfreiche Inhalte, interne Links, gute Seitenerfahrung und glaubwürdige Quellen bleiben auch für generative Suche grundlegend. Google beschreibt GEO und AEO nicht als Ersatz für SEO, sondern ordnet dieselben soliden Grundlagen auch für KI-Sucherlebnisse als relevant ein.

Eine Platzierung lässt sich nicht garantieren. Die beste Grundlage sind öffentliche, crawlbare Inhalte, klare Leistungs- und Unternehmensinformationen, echte Fachbeiträge, Fallstudien, konsistente Daten und glaubwürdige externe Erwähnungen. GEO- und AI-Search-Optimierung erweitert deshalb solide SEO- und Content-Arbeit; es gibt kein geheimes Markup und keine einzelne llms.txt-Datei, die Empfehlungen erzwingt.

Nein. Ein Chatbot ist sinnvoll, wenn er ein konkretes Problem löst: häufige Fragen beantworten, komplexe Informationen durchsuchen, Leads qualifizieren oder Support entlasten. Ein Chatfenster ohne klaren Nutzen erzeugt dagegen Kosten, Datenschutzfragen und Wartungsaufwand. KI-Beratung sollte deshalb beim Prozess beginnen, nicht beim Tool.

Die Herausforderung ist meist nicht das Design, sondern die Zahl der Abhängigkeiten: viele Stakeholder, hunderte URLs, mehrere Sprachen, Rollen und Freigaben, CRM oder ERP, Recruiting, Newsletter, Analytics, Consent, APIs, Security und bestehende Kampagnen. Der Relaunch wird dadurch zu einem Migrations- und Risikomanagementprojekt.

Zuerst werden Inhalte, URLs, Sprachen, Eigentümer und technische Abhängigkeiten inventarisiert. Danach folgen Zielstruktur, Migrationsregeln, Redirect-Mapping, automatisierbare Übernahmen, Stichproben und Freigaben pro Markt oder Inhaltsbereich. Nicht jede alte Seite muss übernommen werden, aber jede bewusste Zusammenführung oder Entfernung braucht eine nachvollziehbare Entscheidung.

Vor dem Umbau werden Systeme, Datenflüsse, Verantwortliche, Authentifizierung und wichtige Ereignisse dokumentiert. Im neuen System werden nicht nur Skripte eingebaut, sondern vollständige Nutzerwege getestet: Anfrage, CRM-Übergabe, Consent, Conversion, Benachrichtigung und Fehlerfall. Monitoring nach dem Go-live gehört zur Migration.

Durch Konten unter Unternehmenskontrolle, dokumentierte Infrastruktur, exportierbare Daten, zugänglichen Quellcode, Backups, klar geregelte Lizenzen und verbreitete Standards, wo sie sinnvoll sind. Individuelle Entwicklung ist nicht automatisch Lock-in; undokumentierte Abhängigkeit schon. Für kritische Systeme sollten zusätzlich Übergabe, Vertretung und Wiederanlauf praktisch planbar sein.