404- und 500-Fehlerseiten im Hyvä-Theme technisch korrekt implementieren
AI generated
Tags Hyvä
Hyvä
phtml
Hyvä · 404 · 500 · SEO
404- und 500-Fehlerseiten im Hyvä-Theme
technisch korrekt gestalten statt nur hübsch anmalen

Wer beim Aufruf einer nicht existierenden URL nur eine generische Fehlermeldung mit HTTP-Status 200 ausliefert, verschenkt Suchmaschinen-Vertrauen und Nutzer gleichermaßen. Dieser Artikel zeigt, wie 404- und 500-Fehlerseiten im Hyvä-Theme technisch sauber implementiert werden, vom Noroute-Controller über den korrekten HTTP-Statuscode bis zum Nginx-Fallback, wenn PHP-FPM selbst nicht mehr antwortet.

12 Min. Lesezeit Noroute-Controller · pub/errors · Nginx-Fallback Magento 2.4.8 · Hyvä CSP

Inhaltsverzeichnis

  1. 1. Warum Standard-Fehlerseiten Conversions kosten
  2. 2. Magentos Noroute-Mechanismus verstehen
  3. 3. Eigenes 404-Template im Hyvä-Theme
  4. 4. Korrekten HTTP-Statuscode erzwingen
  5. 5. Hilfreiche Inhalte statt Sackgasse
  6. 6. 500-Fehler und pub/errors
  7. 7. Fallback auf Webserver-Ebene
  8. 8. CSP auf Fehlerseiten beachten
  9. 9. 404-Tracking und Monitoring
  10. 10. Zusammenfassung
  11. 11. FAQ

1. Warum Standard-Fehlerseiten Conversions kosten

In den meisten Magento-Installationen ist die Fehlerseite das am wenigsten beachtete Template im gesamten Shop. Wer 404- und 500-Fehlerseiten im Hyvä-Theme nur als Design-Aufgabe versteht und dem Standard-CMS-Inhalt lediglich ein neues Logo und ein paar Tailwind-Klassen verpasst, löst damit keines der eigentlichen Probleme. Eine Fehlerseite ist ein technischer Grenzfall des Frameworks, sie entscheidet über den HTTP-Statuscode, der an Suchmaschinen und Monitoring-Systeme kommuniziert wird, über die Frage, ob überhaupt noch PHP-Code ausgeführt werden kann, und darüber, ob ein Besucher nach einem toten Link im Shop bleibt oder abspringt.

Der Unterschied zwischen einer rein visuell gestalteten Fehlerseite und einer technisch fundierten Lösung zeigt sich erst unter Last und in Randfällen: wenn eine Kategorie-URL nach einer Umstrukturierung ins Leere läuft, wenn ein Redis-Ausfall eine 500-Seite erzwingt, oder wenn PHP-FPM selbst nicht mehr antwortet und gar kein Magento-Code mehr läuft. Die folgenden neun Abschnitte behandeln genau diese Fälle und zeigen, wie 404- und 500-Fehlerseiten im Hyvä-Theme so gebaut werden, dass sie SEO-technisch korrekt sind, Besuchern echte nächste Schritte anbieten und auch dann noch etwas ausliefern, wenn der Applikationsserver selbst ausgefallen ist.

2. Magentos Noroute-Mechanismus verstehen

Bevor man eine eigene 404-Seite im Hyvä-Theme baut, lohnt sich ein Blick auf den Mechanismus, den Magento dafür bereits mitbringt. Findet der Router für eine angeforderte URL keine passende Action, wirft Magento\Framework\App\Router\Base intern keine Exception im klassischen Sinn, sondern der Front-Controller fängt das Fehlen einer Route ab und leitet die Anfrage an die im System konfigurierte Noroute-Action weiter. Welche Action das ist, bestimmt die Konfiguration unter web/default/no_route, im Admin unter Stores > Configuration > General > Web > Default Pages > CMS No Route Page. Im Auslieferungszustand zeigt dieser Pfad auf eine simple CMS-Seite, die von Magento\Cms\Controller\Noroute\Index gerendert wird, einem sehr dünnen Controller, der im Kern nur den konfigurierten CMS-Content in die Standard-Page-Struktur einhängt.

Für ein Projekt, das mehr will als reinen CMS-Text, wie etwa Suchvorschläge, individuelle Weiterleitungslogik oder eigenes Logging, ist ein eigener Noroute-Handler die sauberere Lösung als das Zurechtbiegen der CMS-Seite. Ein solches Modul deklariert keinen eigenen Frontnamen in routes.xml, sondern überschreibt gezielt das Layout-Handle, das cms/noroute/index beim Rendern verwendet, und hängt darüber einen eigenen Block samt ViewModel ein. Damit bleibt der komplette Noroute-Mechanismus von Magento unangetastet, während 404- und 500-Fehlerseiten im Hyvä-Theme trotzdem vollständig eigenständigen Code ausführen können.


<?xml version="1.0"?>
<!-- File: app/code/Mironsoft/ErrorPages/view/frontend/layout/cms_noroute_index.xml -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd"
      layout="1column">
    <body>
        <referenceContainer name="content">
            <!-- Remove the default CMS block content of the no-route page -->
            <referenceBlock name="cms_page" remove="true"/>
            <block class="Magento\Framework\View\Element\Template"
                   name="mironsoft.error.404"
                   template="Mironsoft_ErrorPages::noroute/index.phtml">
                <arguments>
                    <argument name="view_model" xsi:type="object">Mironsoft\ErrorPages\ViewModel\ErrorSuggestions</argument>
                </arguments>
            </block>
        </referenceContainer>
    </body>
</page>

3. Eigenes 404-Template im Hyvä-Theme

Ein Hyvä-404-Template unterscheidet sich fundamental von der Luma-Variante, nicht nur optisch, sondern strukturell. Die Luma-Fehlerseite bindet Knockout.js-Komponenten, UI-Component-Layouts und mehrere Legacy-Skript-Bundles ein, selbst wenn die eigentliche Seite nur eine Handvoll Links anzeigt. Ein Hyvä Fehlerseiten gestalten heißt dagegen: ein einzelnes phtml-Template, gestylt ausschließlich mit Tailwind-Utility-Klassen, ohne Knockout-Bindings, ohne data-mage-init-Attribute und ohne UI-Component-Rendering. Interaktivität, etwa ein Live-Filter für Suchvorschläge, kommt vollständig aus Alpine.js, das in jedem Hyvä-Theme ohnehin bereits geladen ist.

Praktisch bedeutet das, dass ein Hyvä-404-Template mit sehr wenig Markup auskommt: ein Template-Block ohne eigene Klasse, ein ViewModel für die dynamischen Daten, und ein phtml, das direkt auf Tailwind-Klassen und Alpine-Direktiven setzt. Der folgende Ausschnitt zeigt genau dieses Muster, inklusive eines kleinen Alpine-Widgets, das Sucheingaben clientseitig gegen eine Liste populärer Suchbegriffe filtert, ohne dafür einen zusätzlichen Server-Request zu benötigen.


<?php
/** @var \Magento\Framework\View\Element\Template $block */
/** @var \Hyva\Theme\Model\ViewModelRegistry $viewModels */
/** @var \Hyva\Theme\ViewModel\HyvaCsp $hyvaCsp */
/** @var \Mironsoft\ErrorPages\ViewModel\ErrorSuggestions $errorSuggestions */
$hyvaCsp = $viewModels->require(\Hyva\Theme\ViewModel\HyvaCsp::class);
$errorSuggestions = $viewModels->require(\Mironsoft\ErrorPages\ViewModel\ErrorSuggestions::class);
$categories = $errorSuggestions->getPopularCategories();
$searchTerms = $errorSuggestions->getPopularSearchTerms();
?>
<!-- File: Mironsoft_ErrorPages/templates/noroute/index.phtml -->
<div
    x-data="{
        query: '',
        terms: <?= /* @noEscape */ json_encode($searchTerms) ?>,
        get suggestions() {
            if (this.query.length < 2) return [];
            return this.terms.filter((t) => t.toLowerCase().includes(this.query.toLowerCase()));
        }
    }"
    class="not-prose max-w-3xl mx-auto py-16 px-4 text-center"
>
    <p class="text-7xl font-bold text-slate-800 mb-4">404</p>
    <p class="text-xl font-semibold text-slate-700 mb-8">Diese Seite wurde nicht gefunden, aber wahrscheinlich meinen Sie eine der folgenden.</p>

    <div class="mb-10">
        <input
            type="text"
            x-model="query"
            placeholder="Wonach haben Sie gesucht?"
            class="w-full border border-slate-300 rounded-xl px-4 py-3 text-base"
        >
        <ul x-show="suggestions.length" class="mt-3 text-left bg-white border border-slate-200 rounded-xl divide-y divide-slate-100">
            <template x-for="term in suggestions" :key="term">
                <li class="px-4 py-2">
                    <a :href="'/catalogsearch/result/?q=' + encodeURIComponent(term)" x-text="term" class="text-orange-700 hover:underline"></a>
                </li>
            </template>
        </ul>
    </div>

    <div class="grid grid-cols-2 sm:grid-cols-3 gap-3">
        <?php foreach ($categories as $category): ?>
            <a href="<?= $block->escapeUrl($category['url']) ?>" class="bg-slate-100 hover:bg-slate-200 rounded-lg px-4 py-3 text-sm font-semibold text-slate-800">
                <?= $block->escapeHtml($category['name']) ?>
            </a>
        <?php endforeach; ?>
    </div>
</div>

<script>
    // Notify listeners that a 404 has actually been rendered, see section 9
    document.addEventListener('DOMContentLoaded', () => {
        document.dispatchEvent(new CustomEvent('error-page:404', { detail: { path: window.location.pathname } }));
    });
</script>
<?= $hyvaCsp->registerInlineScript() ?>

4. Korrekten HTTP-Statuscode erzwingen

Der teuerste Fehler bei 404- und 500-Fehlerseiten im Hyvä-Theme passiert unsichtbar für den Besucher, aber sehr sichtbar für Google: der sogenannte Soft-404. Wenn der Noroute-Controller die Seite zwar korrekt rendert, dabei aber keinen expliziten HTTP-Statuscode setzt, liefert Nginx standardmäßig 200 OK aus, weil aus Sicht des Webservers eine Anfrage erfolgreich beantwortet wurde. Die Google Search Console klassifiziert solche Seiten als Soft-404 und behandelt sie inkonsistent, teils werden sie indexiert, teils herausgefiltert, in jedem Fall verschwendet das wertvolles Crawl-Budget auf Seiten, die eigentlich gar nicht existieren sollten.

Die Lösung liegt in einer einzigen, aber zwingend notwendigen Zeile im eigenen Noroute-Controller oder in einem Plugin auf den Standard-Controller: $this->getResponse()->setHttpResponseCode(404). Wer eine eigene Noroute-Action wie in Abschnitt zwei beschrieben implementiert, sollte diesen Aufruf direkt in der execute()-Methode platzieren, bevor das Ergebnis zurückgegeben wird, nicht erst im Template. Ein Test mit curl -I https://shop.example.com/nicht-vorhandene-url muss danach zuverlässig HTTP/1.1 404 Not Found zeigen, alles andere ist ein Konfigurationsfehler, der sich erst Monate später in schlechteren Rankings bemerkbar macht.

5. Hilfreiche Inhalte statt Sackgasse

Eine 404-Seite im Hyvä-Theme, die nur "Seite nicht gefunden" anzeigt, ist aus Nutzersicht eine Sackgasse. Der Besucher hatte eine Absicht, einen Link angeklickt, eine URL abgetippt oder ein Lesezeichen verwendet, und diese Absicht sollte auf der Fehlerseite so gut wie möglich weiterverfolgt werden können, statt komplett zu verpuffen. Praktisch heißt das: populäre Kategorien als direkte Einstiegspunkte anbieten und die am häufigsten genutzten Suchbegriffe aus dem eigenen Shop als Vorschläge einblenden, statt den Besucher auf eine leere Suchmaske zu verweisen.

Technisch übernimmt diese Aufgabe ein ViewModel, das ArgumentInterface implementiert und zwei Datenquellen kombiniert: die aktiven Top-Level-Kategorien aus der Katalogstruktur und die populärsten Suchbegriffe aus Magentos Search-Query-Log. Beide Quellen sind bereits vorhanden, sie werden im Hyvä-Standard-Setup nur nicht für die Fehlerseite genutzt. Die Konstruktor-Injektion mit Property Promotion in PHP 8.4 hält die Klasse kompakt und typsicher, ohne zusätzliche Setter oder öffentliche Properties.


<?php

declare(strict_types=1);

namespace Mironsoft\ErrorPages\ViewModel;

use Magento\Catalog\Model\ResourceModel\Category\CollectionFactory as CategoryCollectionFactory;
use Magento\Framework\View\Element\Block\ArgumentInterface;
use Magento\Search\Model\Query;
use Magento\Search\Model\ResourceModel\Query\CollectionFactory as SearchQueryCollectionFactory;

/**
 * Supplies popular categories and frequent search terms for the custom
 * 404 template, so a dead end becomes a set of concrete next steps.
 */
final class ErrorSuggestions implements ArgumentInterface
{
    private const CATEGORY_LIMIT = 6;
    private const SEARCH_TERM_LIMIT = 8;

    /**
     * @param CategoryCollectionFactory $categoryCollectionFactory Builds active top-level category collections
     * @param SearchQueryCollectionFactory $searchQueryCollectionFactory Builds popular search term collections
     */
    public function __construct(
        private readonly CategoryCollectionFactory $categoryCollectionFactory,
        private readonly SearchQueryCollectionFactory $searchQueryCollectionFactory
    ) {
    }

    /**
     * Returns the most relevant active categories to offer as navigation shortcuts.
     *
     * @return array<int, array{name: string, url: string}>
     */
    public function getPopularCategories(): array
    {
        $collection = $this->categoryCollectionFactory->create();
        $collection->addAttributeToSelect(['name', 'url_key'])
            ->addAttributeToFilter('is_active', 1)
            ->addAttributeToFilter('level', 2)
            ->addAttributeToSortFilter('position', 'ASC')
            ->setPageSize(self::CATEGORY_LIMIT);

        $result = [];
        foreach ($collection as $category) {
            $result[] = [
                'name' => (string) $category->getName(),
                'url' => (string) $category->getUrl(),
            ];
        }

        return $result;
    }

    /**
     * Returns the most searched terms from Magento's search query log as suggestions.
     *
     * @return string[]
     */
    public function getPopularSearchTerms(): array
    {
        $collection = $this->searchQueryCollectionFactory->create();
        $collection->setPopularQueryFilter()
            ->setPageSize(self::SEARCH_TERM_LIMIT);

        return array_map(
            static fn (Query $query): string => (string) $query->getQueryText(),
            $collection->getItems()
        );
    }
}

6. 500-Fehler und pub/errors

Während 404-Seiten fehlende Routen betreffen, entstehen 500-Fehler, wenn Magento selbst noch läuft, aber eine unbehandelte Exception auftritt, etwa bei einem Datenbank-Timeout, einem defekten Plugin oder einer fehlerhaften Drittanbieter-Erweiterung. Magento fängt solche Fehler über den in pub/errors hinterlegten Report-Mechanismus ab. Standardmäßig existieren dort zwei Verzeichnisse, default und local, jeweils mit einer local.xml, die festlegt, welches Template im Fehlerfall gerendert wird, und ob Debug-Informationen wie Stacktraces angezeigt werden.

Für Produktionsumgebungen aktiviert man über bin/magento beziehungsweise durch Kopieren der local.xml nach pub/errors/local/ den produktionstauglichen Fehlerhandler, der niemals Stacktraces an den Besucher ausliefert, sondern eine generische, aber gebrandete Meldung zeigt. Wichtig für 404- und 500-Fehlerseiten im Hyvä-Theme: Dieses Template liegt außerhalb des regulären Layout- und Theme-Systems, es wird schon vor dem eigentlichen Bootstrap von Magento gerendert, weshalb es kein Tailwind-Build und keine Hyvä-Blockstruktur nutzen kann. Hier reicht ein schlankes, eigenständiges HTML mit inline gehaltenem, minimalem CSS, das lediglich Logo, Farben und einen Link zur Startseite enthält.

7. Fallback auf Webserver-Ebene

Der in Abschnitt sechs beschriebene pub/errors-Mechanismus setzt voraus, dass PHP überhaupt noch ausgeführt werden kann. Genau das ist bei einem echten Server-Crash oft nicht mehr der Fall: Ist der PHP-FPM-Pool ausgelastet, abgestürzt oder wurde er im Rahmen eines fehlgeschlagenen Deployments neu gestartet, kann kein einziges phtml-Template mehr rendern, weil der PHP-Prozess dahinter schlicht nicht antwortet. Ein rein Magento-seitiger Ansatz für 404- und 500-Fehlerseiten im Hyvä-Theme reicht deshalb nicht aus, es braucht eine zweite, komplett unabhängige Ebene direkt im Webserver.

Nginx bietet dafür error_page in Kombination mit einer internen Location, die bei den Statuscodes 502, 503 und 504, also Bad Gateway, Service Unavailable und Gateway Timeout, eine statische HTML-Datei direkt vom Dateisystem ausliefert, ohne den Request erneut an PHP-FPM weiterzureichen. Diese Datei muss vollständig eigenständig sein, mit inline-CSS und ohne Abhängigkeit von externen Assets, denn wenn der Applikationsserver ausfällt, ist oft auch der restliche Static-Content-Pfad nicht garantiert erreichbar. Wer diese Ebene bei einem Varnish-Setup vorschaltet, konfiguriert dieselbe Logik zusätzlich im VCL, damit auch Anfragen, die den Cache umgehen müssen, denselben statischen Fallback erhalten.


# File: /etc/nginx/conf.d/mironsoft-error-fallback.conf
# Serves a fully static HTML page when PHP-FPM itself is unreachable,
# because a phtml template cannot render if the PHP process behind it is dead.

server {
    listen 443 ssl http2;
    server_name mironsoft.de;

    # ... existing ssl_certificate and root directives ...

    error_page 502 503 504 = @php_fpm_down;

    location @php_fpm_down {
        internal;
        root /var/www/html/pub/errors/static;
        rewrite ^ /500-static.html break;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass unix:/var/run/php-fpm/mironsoft.sock;
        fastcgi_intercept_errors on;
        fastcgi_read_timeout 60s;
        include fastcgi_params;
    }
}

8. CSP auf Fehlerseiten beachten

Ein oft übersehener Aspekt, wenn Teams Hyvä Fehlerseiten gestalten: Die Content-Security-Policy verhält sich auf den beiden Fehlerebenen völlig unterschiedlich. Die Hyvä-404-Seite aus Abschnitt drei läuft vollständig innerhalb von Magento und damit innerhalb des Magento_Csp-Moduls. Jeder Inline-Skript-Block in diesem Template muss deshalb genauso über $hyvaCsp->registerInlineScript() registriert werden wie in jedem anderen Hyvä-Template auch, sonst blockiert der Browser das Skript trotzdem, selbst auf einer Fehlerseite.

Die statische Nginx-Fallback-Seite aus Abschnitt sieben liegt dagegen komplett außerhalb von Magento. Es gibt dort keine CSP-Middleware, keine Nonce-Generierung und keinen registerInlineScript()-Aufruf, weil kein PHP-Code mehr läuft, der einen solchen Aufruf ausführen könnte. Für diese Seite gibt es zwei gangbare Wege: entweder komplett auf Inline-JavaScript verzichten und nur reines HTML mit inline-CSS ausliefern, oder eine feste CSP über einen zusätzlichen add_header Content-Security-Policy direkt in der Nginx-Location setzen, mit einem statisch berechneten Hash für den einen erlaubten Inline-Block. Die erste Variante ist robuster, weil sie überhaupt keine Angriffsfläche für Skript-Injection auf der letzten Verteidigungslinie des Shops bietet.

9. 404-Tracking und Monitoring

Eine gut gestaltete 404-Seite im Hyvä-Theme löst das Symptom, verhindert aber nicht die Ursache: kaputte interne Links, veraltete Backlinks oder falsch konfigurierte Weiterleitungen nach einer Kategorie-Umstrukturierung. Ohne systematisches Tracking bleiben diese Quellen unsichtbar, der Shop verliert kontinuierlich Traffic, ohne dass jemand merkt, woher die 404-Aufrufe eigentlich kommen. Ein GA4-Event, das bei jedem gerenderten 404-Template ausgelöst wird, macht diese Lücke sichtbar und lässt sich in Reports nach Pfad und Referrer auswerten.

Technisch reicht dafür ein kleines Skript, das auf das im phtml-Template aus Abschnitt drei ausgelöste Custom Event error-page:404 reagiert und einen entsprechenden Eintrag in window.dataLayer schreibt. Wer zusätzlich serverseitiges Logging möchte, ergänzt im Noroute-Controller einen einfachen Logger-Aufruf mit angeforderter URL und Referrer-Header, das erlaubt eine spätere Auswertung auch dann, wenn ein Besucher JavaScript deaktiviert hat oder ein Consent-Banner das Tracking-Skript blockiert.


// File: web/js/error-tracking.js
// Fires a GA4-compatible dataLayer event for every rendered 404 page,
// so broken internal links surface in analytics instead of staying invisible.
window.dataLayer = window.dataLayer || [];

document.addEventListener('error-page:404', (event) => {
    window.dataLayer.push({
        event: 'error_404',
        error_path: event.detail.path,
        error_referrer: document.referrer || '(direct)',
    });
});

Im Zusammenspiel ergibt sich ein klares Bild, wie sich die Standard-Auslieferung von Magento und eine bewusst gebaute Hyvä-Lösung für 404- und 500-Fehlerseiten im Hyvä-Theme unterscheiden.

Dimension Magento Standard Empfohlene Hyvä-Implementierung Vorteil
HTTP-Status bei falscher URL oft 200 OK (Soft-404) explizit 404 via setHttpResponseCode() Korrekte Signale an Suchmaschinen
SEO-Auswirkung Crawl-Budget auf toten Seiten verschwendet Seite wird korrekt aus dem Index gehalten Bessere Rankings, saubere Search Console
Nutzerführung statischer CMS-Text, keine Vorschläge Suchvorschläge + populäre Kategorien Geringere Absprungrate
Verhalten bei PHP-FPM-Ausfall Timeout oder Proxy-Fehlerseite statisches HTML-Fallback via Nginx Gebrandete Antwort auch im Ernstfall
CSP-Konformität Inline-Skripte oft ohne Nonce registerInlineScript() bzw. kein Inline-JS im Fallback Kein CSP-Verstoß, keine Angriffsfläche

10. Zusammenfassung

404- und 500-Fehlerseiten im Hyvä-Theme sind kein reines Design-Thema, sondern ein Zusammenspiel aus Routing, HTTP-Semantik und Infrastruktur-Resilienz. Der Noroute-Mechanismus von Magento liefert die Grundlage, ein eigenes Layout-Handle und ein Hyvä-natives Template ersetzen die generische CMS-Seite durch echte Tailwind- und Alpine.js-Struktur. Der korrekte HTTP-Statuscode verhindert Soft-404-Probleme, ein ViewModel mit Suchvorschlägen macht aus einer Sackgasse einen nützlichen Einstiegspunkt, und pub/errors übernimmt die Behandlung echter 500-Fehler innerhalb der Applikation.

Der entscheidende, oft vergessene Baustein ist die Ebene unterhalb von Magento: Ein statischer Nginx-Fallback greift genau dann, wenn PHP-FPM selbst nicht mehr antwortet und keine einzige phtml-Datei mehr rendern kann. Zusammen mit CSP-konformer Skript-Registrierung und einem einfachen 404-Tracking-Event ergibt das eine vollständige, produktionstaugliche Lösung für 404- und 500-Fehlerseiten im Hyvä-Theme, die sowohl in Suchmaschinen als auch im echten Ausfall zuverlässig funktioniert.

404- und 500-Fehlerseiten im Hyvä-Theme, das Wichtigste auf einen Blick

Noroute-Mechanismus

Eigenes Layout-Handle für cms/noroute/index statt CMS-Seite umzubauen, damit ViewModel und eigene Logik sauber eingehängt werden.

Korrekter HTTP-Status

setHttpResponseCode(404) explizit im Controller setzen, sonst entsteht ein Soft-404, der Crawl-Budget verschwendet.

Nginx-Fallback

Statisches HTML über error_page 502 503 504, weil kein phtml rendert, wenn PHP-FPM selbst ausgefallen ist.

404-Tracking

GA4-Event pro 404-Aufruf macht kaputte interne Links und veraltete Backlinks sichtbar und auswertbar.

11. FAQ: 404- und 500-Fehlerseiten im Hyvä-Theme

1Unterschied 404 vs. 500 im Hyvä-Theme?
404 entsteht bei fehlender Route, die Anwendung läuft normal weiter. 500 entsteht durch eine unbehandelte Exception innerhalb der laufenden Anwendung.
2Reicht reines Design der Fehlerseite?
Nein, Design allein löst weder das Soft-404-Problem noch den Fall, in dem PHP-FPM selbst ausgefallen ist und kein Template mehr rendert.
3Was steuert web/default/no_route?
Legt fest, welche CMS-Seite bei fehlender Route gerendert wird, ausgewertet von Magento\Cms\Controller\Noroute\Index.
4Wann eigener Noroute-Controller statt CMS-Seite?
Sobald Suchvorschläge, dynamische Inhalte oder eigenes Logging benötigt werden, per eigenem Layout-Handle für cms_noroute_index.
5Was ist ein Soft-404?
Eine Fehlerseite, die HTTP 200 statt 404 liefert. Google behandelt sie inkonsistent und verschwendet Crawl-Budget.
6Wie erzwinge ich den korrekten HTTP-Status?
setHttpResponseCode(404) explizit im Controller aufrufen, vor der Rückgabe des Ergebnisses. Mit curl -I testen.
7Was hat pub/errors mit 500-Fehlern zu tun?
Enthält den Report-Mechanismus für unbehandelte Exceptions, local.xml in pub/errors/local steuert das Produktions-Template.
8Warum reicht pub/errors bei PHP-FPM-Ausfall nicht?
Setzt laufendes PHP voraus. Fällt PHP-FPM aus, rendert kein phtml mehr, ein statischer Nginx-Fallback ist zwingend nötig.
9Muss der Fallback die Hyvä-CSP einhalten?
Der Fallback läuft außerhalb von Magento, ohne registerInlineScript(). Reines HTML mit inline-CSS ohne Inline-JavaScript ist am robustesten.
10Wie tracke ich 404-Aufrufe?
Custom Event aus dem Template füttert window.dataLayer für GA4, ergänzend serverseitiges Logging von Pfad und Referrer im Controller.

Mironsoft

Hyvä-Entwicklung, SEO-Technik und resiliente Magento-Infrastruktur

404- und 500-Fehlerseiten im Hyvä-Theme, technisch statt nur visuell?

Wir bauen euren Noroute-Handler, den korrekten HTTP-Statuscode, ein hilfreiches Hyvä-404-Template und einen statischen Nginx-Fallback für den Ernstfall, sauber gegen eure produktive CSP-Konfiguration getestet.

SEO-Audit

Bestehende Fehlerseiten auf Soft-404 und falsche HTTP-Statuscodes prüfen

Hyvä-404-Template

Noroute-Controller, ViewModel mit Suchvorschlägen und Alpine.js-Widget

Nginx-Fallback

Statisches HTML für den Fall, dass PHP-FPM selbst nicht mehr antwortet

Kostenloses Erstgespräch Fehlerseiten-Audit anfragen