SEO-Infrastruktur Magdeburg

Technisches SEO für Magdeburg — entlang des Pfads, den Google nimmt

Magdeburger B2B-Websites laufen oft auf Stacks, die nach Funktion gewachsen sind, nicht nach Performance: Speditionen mit schweren Tracking-Toolchains, Maschinenbauer mit gewachsenem WordPress samt einem Dutzend Plugins, Universitäts-Spin-offs auf Custom-Frameworks. Technisches SEO ist die unsichtbare Hälfte der Suchmaschinenoptimierung — funktioniert es, merkt niemand etwas; bricht es, fallen Rankings, oft ohne erkennbaren Grund. Wir prüfen die Technik dort, wo der Googlebot ansetzt: Stufe für Stufe.

Kostenloses Beratungsgespräch Pakete & Preise

Die stillen Fehler — und warum sie in Magdeburg häufig sind

Technische SEO-Probleme machen selten Lärm. Eine Seite, die der Googlebot wegen einer falschen robots.txt-Regel nicht crawlt, sieht im Browser völlig normal aus. Ein Canonical-Tag, der irrtümlich auf die Startseite zeigt, fällt im Tagesgeschäft niemandem auf. Erst wenn die Sichtbarkeit über Wochen abrutscht, beginnt die Ursachensuche — und endet oft genau hier.

In Magdeburg häufen sich diese stillen Fehler, weil viele Stacks nach Funktion statt nach Performance gewachsen sind. Statt das in acht abstrakte Felder zu zerlegen, prüfen wir entlang des Wegs, den Google tatsächlich nimmt: erst hineinkommen, dann rendern, dann das Tempo, dann die Bedeutung, am Ende die Absicherung. Diese fünf Stufen strukturieren jedes technische Audit, das wir liefern.

Fünf Stufen entlang des Crawler-Pfads

Stufe 1

Reinkommen — darf Google überhaupt?

robots.txt, XML-Sitemaps, Crawl-Budget und saubere Canonical-Tags. Bei gewachsenen Magdeburger Mittelstands-Sites blockiert hier oft eine alte robots-Regel oder ein verwaister Canonical auf die Startseite ganze Bereiche, ohne dass es im Browser auffällt.

Stufe 2

Rendern — sieht Google die Inhalte?

Indexierbarkeit, JavaScript-Rendering und Mobile-First. Logistik-Anbieter mit schweren Tracking-Toolchains und Universitäts-Spin-offs auf Custom-Frameworks liefern Google häufig eine andere Seite als dem Nutzer — hier prüfen wir, ob Server-Side Rendering oder Static Generation nötig ist.

Stufe 3

Tempo — wie schnell reagiert die Seite?

Core Web Vitals als Felddaten gemessen: LCP, INP und CLS. Eine WordPress-Installation mit einem Dutzend Plugins und aktivem Page-Builder reißt hier regelmäßig die INP-Grenze. Wir sanieren am Frontend-Code, nicht pauschal an Hosting oder Theme.

Stufe 4

Verstehen — kann Google die Bedeutung lesen?

Schema.org JSON-LD direkt im Quelltext: LocalBusiness, FAQPage, BreadcrumbList, Article, Product. Damit verwandeln wir nackte Treffer in Rich Results. Für Landesbehörden und Bildungseinrichtungen zählt zusätzlich saubere Auszeichnung von Öffnungszeiten, Standorten und Ansprechpartnern.

Stufe 5

Absichern — bleibt es sauber?

HTTPS mit TLS 1.3, HSTS, schlanke Redirect-Ketten, keine Mixed-Content-Fehler und Security-Header (CSP, X-Content-Type-Options, Referrer-Policy). Bei mehrsprachigen Seiten dazu hreflang und x-default — relevant, sobald Magdeburger Exporteure international auffindbar sein wollen.

Stufe 3 im Detail: warum Tempo über INP entschieden wird

Von allen fünf Stufen ist das Tempo die, an der Magdeburger Mittelstands-Sites am häufigsten scheitern. Seit 2024 misst Google es über INP (Interaction to Next Paint) statt über das alte FID. INP erfasst nicht die erste, sondern die schlechteste Interaktion einer Sitzung — und ist damit deutlich strenger.

Eine typische WordPress-Seite mit zwölf und mehr Plugins und aktivem Page-Builder erreicht heute oft INP-Werte von 400 bis 800 Millisekunden, wo unter 200 das Ziel wäre. Nutzer spüren das unmittelbar: Klicks reagieren träge, Formulare hängen kurz, Menüs öffnen verzögert. Google wertet das als schlechte Nutzererfahrung und stuft die Seite niedriger ein. Wir messen mit echten Felddaten aus CrUX und RUM — Lab-Werte unterschätzen genau diese Mobile-Probleme — und sanieren gezielt am Frontend-Code statt pauschal alles auszutauschen.

Stufe 4 im Detail: Schema, das in Magdeburger Branchen wirkt

Strukturierte Daten entscheiden, ob aus einem nackten Treffer ein Rich Result wird — und welche Schema-Typen sich lohnen, hängt an der Branche. Statt einer generischen Liste gewichten wir nach Magdeburger Realität:

  • FAQPage für beratungsintensive Dienstleister, die so zusätzliche Klick-Fläche in der SERP gewinnen.
  • LocalBusiness für stadtteilbezogene Anbieter — die Voraussetzung für viele Local-Pack-Features in Buckau, Sudenburg oder Stadtfeld.
  • Product mit Bewertungen für Maschinen- und Anlagenbauer mit Katalogseiten, sofern echte Reviews vorliegen.
  • BreadcrumbList, um in der SERP lesbare Brotkrumen statt einer rohen URL zu zeigen — wertvoll bei tief verschachtelten Behörden-Sites.
  • Article für das Forschungs- und Wissens-Umfeld rund um die Otto-von-Guericke-Universität.

Wir implementieren diese Auszeichnungen mit zentralen Komponenten direkt im Quelltext — nicht über ein Plugin, das eine spätere Migration teuer macht — und validieren sie laufend gegen den Schema.org-Test und das Rich-Results-Reporting der Search Console.

Häufige Fragen zu technischem SEO

Worin unterscheidet sich technisches SEO von einer SEO-Analyse?

Die Analyse ist die einmalige Bestandsaufnahme, die die Probleme aufdeckt und priorisiert. Technisches SEO ist die laufende Umsetzung daran — wir greifen aktiv in Code, Konfiguration und Render-Verhalten ein. Viele Magdeburger Kunden starten mit der Analyse und beauftragen anschließend gezielt die technische Umsetzung der gefundenen Punkte.

Unsere Logistik-Website lädt langsam wegen vieler Tracking-Tools — lässt sich das beheben?

In der Regel ja, ohne alles zu verwerfen. Schwere Tracking- und Tag-Manager-Ketten sind eine der häufigsten INP-Bremsen, die wir bei Magdeburger Speditions- und Hafenlogistik-Seiten sehen. Wir messen zuerst mit Felddaten, identifizieren die tatsächlich blockierenden Skripte und laden sie verzögert oder serverseitig — statt das Tracking ganz zu opfern.

Müssen wir für gutes technisches SEO neu bauen?

Meistens nicht. Fehlende Schema-Auszeichnung, kaputte Canonicals, blockierende Skripte oder verschwendetes Crawl-Budget lassen sich am bestehenden System beheben. Ein Neubau ist nur sinnvoll, wenn der Stack grundsätzlich nicht renderbar oder nicht wartbar ist — etwa ein altes Custom-Framework aus einem OVGU-Spin-off ohne SSR. Das sagen wir ehrlich, statt unnötig einen Relaunch zu verkaufen.

Warum messt ihr Core Web Vitals mit Felddaten statt mit Lab-Werten?

Weil Lab-Daten Mobile-Probleme systematisch unterschätzen. Der entscheidende Wert ist seit 2024 INP (Interaction to Next Paint), der nicht die erste, sondern die schlechteste Interaktion einer Sitzung misst — hängende Klicks, träge Menüs, verzögerte Formulare. Das zeigt sich erst in echten Felddaten aus CrUX und RUM. Gute Werte liegen unter 200 Millisekunden.

Implementiert ihr Schema.org über ein Plugin?

Nein. Wir setzen Schema.org JSON-LD mit zentralen Komponenten direkt im Quelltext um, nicht über ein Plugin, das eine spätere Migration teuer macht. Anschließend validieren wir laufend gegen den Schema.org-Test und das Rich-Results-Reporting der Search Console.