sitemap.xml in google search console nicht gefunden obwohl im Browser aufrufbar

**conter** · 10.06.2025, 10:50

Hallo zusammen,

ich habe vor dem Wochenende eine DE/EN Website in die google search console eingetragen, verifiziert usw. und sitemap.xml eingegeben.
Über domain.tld/sitemap.xml kriege ich die Sitemap angezeigt.
GSC meldet aber, sitemap kann nicht kann nicht abgerufen werden ...
sitemap.png
Hat jemand eine Idee, woran das liegen kann?

PS. domain.tld/sitemap.xml zeigt in chrome devtools Console den Fehler

Code:

Uncaught TypeError: Cannot read properties of undefined (reading 'charAt')
    at r (content.bundle.js:1:14150)
    at content.bundle.js:1:14196
    at 89658 (content.bundle.js:1:14308)
    at n (content.bundle.js:1:75738)
    at 61105 (content.bundle.js:1:370)
    at n (content.bundle.js:1:75738)
    at 86492 (content.bundle.js:1:10415)
    at n (content.bundle.js:1:75738)
    at 86824 (content.bundle.js:1:9913)
    at n (content.bundle.js:1:75738)

Kann das was damit zu tun haben?

Viele Grüße,
Meike

**Spooky** · 10.06.2025, 10:53

Poste die echte Domain.

**conter** · 10.06.2025, 10:59

https://www.gastek.eu/sitemap.xml

**Spooky** · 10.06.2025, 11:00

Prüfe es einfach in einer Woche oder einem Monat nochmal.

**conter** · 10.06.2025, 11:14

Meinst du einfach warten? Oder noch mal neu absenden in einer Woche?

Aber, wenn es grundsätzlich richtig konfiguriert ist, ist ja schon mal gut.

**Spooky** · 10.06.2025, 18:07

Zitat von conter

https://www.gastek.eu/sitemap.xml

Btw. die Server Config passt noch nicht ganz - folgendes führt zu 404: https://www.gastek.eu/robots.txt

Nachdem das vom nginx kommt ist dort vermutlich eine spezifische Rule für /robots.txt ohne try_files konfiguriert.

**conter** · 11.06.2025, 11:03

Moin,

wenn ich eine robots.txt über SFTP in public hochlade, wird sie gefunden und angezeigt.
Wenn ich nur im Startpunkt der Website User-agent: * eintrage gibt es den 404er.

Contao legt ja keine statische txt an sondern nur den Meta-Tag <meta name="robots" content="index,follow">, wie soll das direkte Aufrufen von https://www.domain.tld/robots.txt dann keinen Fehler ausgeben?

In der nginx-Konfiguration taucht das Wort "robots" nicht auf. Sollte ich es irgendwie / wie? mit eintragen?

Code:

location /files {
  alias  /var/www/clients/client3/web479/web/v2/files;
}

# brotli

brotli on;
brotli_comp_level 6; 
brotli_types 
    text/html 
    text/plain 
    text/css 
    text/javascript 
    application/javascript 
    application/x-javascript 
    application/json 
    application/xml 
    application/xhtml+xml 
    application/atom+xml 
    application/rss+xml 
    image/svg+xml 
    image/x-icon 
    image/webp 
    font/ttf 
    font/otf 
    font/woff 
    font/woff2;

# - Web-Path zusätzlich anpassen/uebergeordnetes Verzeichnis hinzufuegen (PHP open_basedir:) # - Rechte fuer uebergeordnetes Verzeichnis anpassen # - PHP Optionen fuer Phar setzen

##ccm##

  set $ccm19_urlpath /ccm/ccm19;

  # Den folgenden Path entsprechend der Domain anpassen
  # set $ccm19_realpath /var/www/<DOMAIN>/.../ccm/ccm19/public;
  set $ccm19_realpath /var/www/www.gastek.eu/web/v2/public/ccm/ccm19/public;
  
  location ~ /ccm/ccm19(/.*) {
      root $ccm19_realpath;
      try_files $1 @ccm19;
  }

  location ^~ /ccm/ccm19/index.php {
      return 403;
  }

  location @ccm19 {
      root $ccm19_realpath;

      fastcgi_index index.php;
      fastcgi_split_path_info ^(/ccm/ccm19)(/.*)$;
      set $path_info $fastcgi_path_info;

      fastcgi_param SCRIPT_FILENAME $document_root/index.php;
      fastcgi_param SCRIPT_NAME $ccm19_urlpath/index.php;
      fastcgi_param PATH_INFO $path_info;

      fastcgi_param HTTP_PROXY "";
      fastcgi_param QUERY_STRING $query_string;
      fastcgi_param REQUEST_METHOD $request_method;
      fastcgi_param CONTENT_TYPE $content_type;
      fastcgi_param CONTENT_LENGTH $content_length;
      fastcgi_param REQUEST_URI $request_uri;
      fastcgi_param DOCUMENT_URI $document_uri;
      fastcgi_param DOCUMENT_ROOT $document_root;
      fastcgi_param SERVER_PROTOCOL $server_protocol;
      fastcgi_param REQUEST_SCHEME $scheme;
      fastcgi_param HTTPS $https if_not_empty;
      fastcgi_param GATEWAY_INTERFACE CGI/1.1;
      fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
      fastcgi_param REMOTE_ADDR $remote_addr;
      fastcgi_param REMOTE_PORT $remote_port;
      fastcgi_param SERVER_ADDR $server_addr;
      fastcgi_param SERVER_PORT $server_port;
      fastcgi_param SERVER_NAME $server_name;

      {FASTCGIPASS}
  }

##ende ccm##

location / {

client_max_body_size 100M;

##index app.php; try_files $uri $uri/ /app.php$is_args$args;
index index.php; try_files $uri $uri/ /index.php$is_args$args;

##location ~ ^/(app|app_dev|config|install|preview|contao-manager\.phar)\.php(/|$) {
location ~ ^/(index|index_dev|config|preview|contao-manager\.phar)\.php(/|$) {

include /etc/nginx/fastcgi_params;
            {FASTCGIPASS}
#fastcgi_pass unix:/var/lib/php7.2-fpm/web41.sock;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;

fastcgi_temp_file_write_size 10m;
fastcgi_busy_buffers_size    512k;
fastcgi_buffer_size          512k;
fastcgi_buffers           16 512k;
fastcgi_read_timeout 1200;
fastcgi_param HTTP_AUTHORIZATION $http_authorization;

}

}

location ~ \.(css|js|ico|woff|woff2|pdf|svg|jpg|jpeg|png|gif|webp|txt)$ {

 expires 6M;
 add_header Pragma "public";
 try_files $uri $uri/ /index.php$is_args$args;

}

open_file_cache max=2000 inactive=20s; open_file_cache_valid 60s; open_file_cache_min_uses 5; open_file_cache_errors off;

Viele Grüße,
conter

**Spooky** · 11.06.2025, 11:21

Zitat von conter

wenn ich eine robots.txt über SFTP in public hochlade, wird sie gefunden und angezeigt.

Ja, darum geht es aber nicht - es geht darum, dass die dynamische Route von Contao funktionieren muss, was aktuell bei dir nicht der Fall ist.

Zitat von conter

Contao legt ja keine statische txt an sondern nur den Meta-Tag <meta name="robots" content="index,follow">, wie soll das direkte Aufrufen von https://www.domain.tld/robots.txt dann keinen Fehler ausgeben?

Das ist eine dynamische Route.

Zitat von conter

In der nginx-Konfiguration taucht das Wort "robots" nicht auf. Sollte ich es irgendwie / wie? mit eintragen?

Poste die Konfiguration.

**Spooky** · 11.06.2025, 11:26

Zitat von conter

In der nginx-Konfiguration taucht das Wort "robots" nicht auf. Sollte ich es irgendwie / wie? mit eintragen?

robots nicht, aber txt:

Zitat von conter

Code:

location ~ \.(css|js|ico|woff|woff2|pdf|svg|jpg|jpeg|png|gif|webp|txt)$ {

 expires 6M;
 add_header Pragma "public";
 try_files $uri $uri/ /index.php$is_args$args;

}

Aber evt. greift hier noch etwas anderes - denn try_files wäre da ja drin (sonst würden bei dir ja auch Bilder nicht funktionieren).

**conter** · 11.06.2025, 13:34

Hallo zusammen,

ich habe noch mal bei der IT nachgefragt und mit

Code:

location = /robots.txt {
    try_files $uri /app.php$is_args$args;
}

# -------------------------------------
# Statische Dateien mit Langzeit-Caching (ausgenommen .txt, um Konflikte zu vermeiden)
# -------------------------------------
location ~ \.(css|js|ico|woff|woff2|svg|jpg|jpeg|png|gif|webp)$ {
    expires 6M;
    add_header Pragma "public";
    try_files $uri $uri/ /app.php$is_args$args;
}

funktioniert es jetzt mit der dynamischen Route.

Danke und viele Grüße,
conter

**Thomas Pyrin** · 07.01.2026, 08:27

Ich habe das gleiche Problem, Webserver Apache

die sitemap.xml und die robots.txt ist im Browser abrufbar, aber die Google Search Console meldet einen 404 bei abruf der Sitemap und der robots.txt

was kann ich genau tun?

Danke

**stefan-at-work** · 07.01.2026, 10:36

Prüfe mal bitte, ob einer dieser Aufrufe einen 404 erzeugt:

https://example.com/robots.txt
https://www.example.com/robots.txt
http://example.com/robots.txt
http://www.example.com/robots.txt

Wenn ja, liegt es an einer fehlenden Umleitung. In der Search Console muss genau die Property eingetragen sein, für die die Dateien wirklich existieren und per 301 sauber auf die Hauptdomain weitergeleitet werden.

Gesendet von iPhone mit Tapatalk

**Thomas Pyrin** · 07.01.2026, 11:13

Die Property ist ja mit www eingetragen.

Alle 4 Beispiele werden im Browser korrekt angezeigt.

**Thomas Pyrin** · 07.01.2026, 11:28

In die htaccess habe ich noch eingefügt:

HTML-Code:

 # Immer HTTPS + www erzwingen
    RewriteCond %{HTTPS} !=on [OR]
    RewriteCond %{HTTP_HOST} !^www\.meinedomain\.com$ [NC]
    RewriteRule ^ https://www.meinedomain.com%{REQUEST_URI} [L,R=301]

Im Browser sind alle vier Beispiele abrufbar - die Testergebnisse sind per PHP Abruf aber so:

HTML-Code:

$url = "https://www.meinedomain.com/sitemap.xml";
$header_response = get_headers($url, 1);
var_dump($header_response[0]);
=> HTTP/1.1 404 Not Found

$url = "https://meinedomain.com/sitemap.xml";
$header_response = get_headers($url, 1);
var_dump($header_response[0]);
=> HTTP/1.1 301 Moved Permanently

$url = "http://www.meinedomain.com/sitemap.xml";
$header_response = get_headers($url, 1);
var_dump($header_response[0]);
=> HTTP/1.1 301 Moved Permanently

$url = "http://meinedomain.com/sitemap.xml";
$header_response = get_headers($url, 1);
var_dump($header_response[0]);
=> HTTP/1.1 301 Moved Permanently

**Thomas Pyrin** · 07.01.2026, 12:12

Kann es sein, dass Contao / Symfony eine 404 sendet, weil es keine "echte" Seite ist, sondern ein Routing?

Und wenn ja, was kann man tun?

**Spooky** · 07.01.2026, 12:29

Poste mal die echte Domain.

**Thomas Pyrin** · 07.01.2026, 12:47

https://www.sonnenplaner.com/sitemap.xml
=> wird im Browser aufgerufen - CURLINFO_HTTP_CODE liefert 404

http://www.sonnenplaner.com/sitemap.xml
=> wird im Browser aufgerufen - auf https umgeleitete - CURLINFO_HTTP_CODE liefert 404

https://sonnenplaner.com/sitemap.xml
=> Contao 404 Fehlerseite - CURLINFO_HTTP_CODE liefert 404

http://sonnenplaner.com/sitemap.xml
=> Contao 404 Fehlerseite - CURLINFO_HTTP_CODE liefert 404

Bei den beiden ohne www greift auch nicht die htaccess Regel:

HTML-Code:

# Immer HTTPS + www erzwingen
    RewriteCond %{HTTPS} !=on [OR]
    RewriteCond %{HTTP_HOST} !^www\.sonnenplaner\.com$ [NC]
    RewriteRule ^ https://www.sonnenplaner.com%{REQUEST_URI} [L,R=301]

**Spooky** · 07.01.2026, 12:50

Ja, du musst rausfinden, warum bei dir ein 404 Status Code gesendet wird. Könnte bspw. auch vom Web Server gesetzt worden sein. Ansonsten aber mal direkt das PHP Response Objekt prüfen.

**Thomas Pyrin** · 07.01.2026, 13:00

Ich hab mal den Support angeschrieben.

Warum funktioniert bei den SiteMap ohne www die Weiterleitung auf www nicht - trotz der zusätzlichen Anweisung im htaccess

Kann ich das direkt in den Seiteneinstellungen noch direkt konfigurieren?

**Spooky** · 07.01.2026, 13:07

Zitat von Thomas Pyrin

Warum funktioniert bei den SiteMap ohne www die Weiterleitung auf www nicht - trotz der zusätzlichen Anweisung im htaccess

Code:

$ curl -I http://sonnenplaner.com/sitemap.xml
HTTP/1.1 301 Moved Permanently
Date: Wed, 07 Jan 2026 12:06:49 GMT
Server: Apache
Location: https://www.sonnenplaner.com/404.shtml
Cache-Control: max-age=0
Expires: Wed, 07 Jan 2026 12:06:49 GMT
Content-Type: text/html; charset=iso-8859-1

Der Webserver will hier auf "404.shtml" weiterleiten.

Bei welchem Hoster bist du?

**Thomas Pyrin** · 07.01.2026, 13:08

HostEurope cPanel Hosting

**Thomas Pyrin** · 07.01.2026, 13:10

Komisch nur, dass die htaccess Anweisung permanent auf www umzuleiten, bei der sitemap.xml nicht greift. Bei "normalen" Seiten klappt das.

**Spooky** · 07.01.2026, 13:11

Zitat von Thomas Pyrin

Komisch nur, dass die htaccess Anweisung permanent auf www umzuleiten, bei der sitemap.xml nicht greift. Bei "normalen" Seiten klappt das.

Siehe oben - der Webserver leitet immer auf https://www.sonnenplaner.com/404.shtml

**do_while** · 07.01.2026, 16:13

Hast Du vielleicht in den Sitemaps einen Schreibfehler in der URL bei Google hinterlegt?

**Spooky** · 07.01.2026, 16:18

Zitat von do_while

Hast Du vielleicht in den Sitemaps einen Schreibfehler in der URL bei Google hinterlegt?

Daran liegt es nicht, der 404 Status code ist auf jeden Fall da (siehe oben).

**Thomas Pyrin** · Gestern, 14:33

es ist leider immer noch so - die Umleitung vom cPanel ist es nicht:

HTML-Code:

curl -i http://sonnenplaner.com/sitemap.xml
HTTP/1.1 404 Not Found
Date: Wed, 21 Jan 2026 13:31:01 GMT
Server: Apache
X-Powered-By: PHP/8.3.28, PHP/8.3.28
Cache-Control: public, s-maxage=2592000
vary: Origin,Cookie,Accept-Encoding
x-content-type-options: nosniff
referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-digest: enb145a0afd22380035e6adf8bc982a479
Age: 22
Contao-Cache: fresh
Upgrade: h2,h2c
Connection: Upgrade
content-length: 18620
Content-Type: application/xml; charset=UTF-8

Es wird zwar eine Sitemap ausgeliefert, aber der HTTP Response ist ein 404
Das gleiche gilt für die robots.txt

Kann man mit einem Plugin die sitemap wieder hart generieren, dass die nicht dynamisch generiert wird?
Oder kann ich beim generieren zur LIVE Zeit den HTTP Code auf 200 setzen?

**Spooky** · Gestern, 14:36

Zitat von Thomas Pyrin

Es wird zwar eine Sitemap ausgeliefert, aber der HTTP Response ist ein 404
Das gleiche gilt für die robots.txt

Genau, das musst du weiter analysieren, warum das so ist.

**Thomas Pyrin** · Gestern, 14:45

Und es ist sicher, dass Contao das nicht so ausliefert? Weil es zur LiveZeit generiert wird?

**Spooky** · Gestern, 14:56

Zitat von Thomas Pyrin

Und es ist sicher, dass Contao das nicht so ausliefert?

Wenn Contao das so machen würde, würde es ja bei niemanden funktionieren

Oder meinst du, ob der Status von PHP oder vom Web Server kommt? Das ist eines der ersten Dinge, die du analysieren musst.

**Thomas Pyrin** · Gestern, 15:16

curl -v http://sonnenplaner.com/sitemap.xml 2>&1 | grep -i "X-Powered-By\|HTTP/1"
> GET /sitemap.xml HTTP/1.1
< HTTP/1.1 404 Not Found
< X-Powered-By: PHP/8.3.28, PHP/8.3.28

Das sieht m.E auch, dass es vom PHP kommt.

Das doppelte PHP/8.3.28, PHP/8.3.28 könnte ein interner Forward sein?

**Spooky** · Gestern, 15:18

Ja, die ursprüngliche Antwort wird natürlich von PHP generiert, geht ja auch nicht anders. Aber der Status könnte theoretisch vom Webserver überschrieben worden sein. Daher musst du als erstes prüfen, ob der Status schon wenn die Antwort von PHP an den Browser geschickt wird (bzw. an den Web Server übergeben wird) bereits 404 ist, oder nicht.

**Thomas Pyrin** · Gestern, 15:45

Gefunden!
Übergeordnet lag noch eine htaccess, die für die 404 gesorgt hatte

Man, man, man ..... danke

**mlweb** · Gestern, 18:08

Solche "vergessenen" oder "unbekannten" .htaccess-Dateien, die man möglicherweise selbst gar sieht, weil man keinen Zugriff auf den übergeordneten Ordner hat, haben schon manches Problem verursacht. Liest man auch gar nicht so selten hier im Forum.

Thema: sitemap.xml in google search console nicht gefunden obwohl im Browser aufrufbar

Themen-Optionen

Thema durchsuchen

sitemap.xml in google search console nicht gefunden obwohl im Browser aufrufbar

Aktive Benutzer

Aktive Benutzer

Berechtigungen