Probleme mit Drupal 10 - HTTP Statuscode 403 (gelöst)
Eingetragen von beaschmitz (469)am 09.03.2025 - 10:01 Uhr in
Hallo zusammen,
leider komme ich bei einem Punkt nicht weiter:
meine Drupal Installation (10) blockiert anscheinend alle Crawler und der Hoster (WebhostOne) meint, es ist meine .httacces Datei.
Ich habe schon gesucht aber habe keine Ahnung im Detail, was hier noch falsch sein könnte.
Ich habe wohl gelesen, dass der Compaser leider die Datei bei einem Update irgendwie überschreibt... Vermutlich ist dies hier geschehen. Ich finde aber den Fehler nicht :(
Ich kopiere die Daten aus der Datei mal hier rein und hoffe, es kennt sich jemand aus damit.
Bestenfalls muss ich ja nur etwas auskommentieren?
Danke und Gruß!
#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl(\.php)?|xtmpl|yml)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
</IfModule>
</FilesMatch>
# Don't show directory listings for URLs which map to a directory.
Options -Indexes
# Set the default handler.
DirectoryIndex index.php index.html index.htm
# Add correct encoding for SVGZ.
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
# Most of the following PHP settings cannot be changed at runtime. See
# sites/default/default.settings.php and
# Drupal\Core\DrupalKernel::bootEnvironment() for settings that can be
# changed at runtime.
# PHP 7, Apache 1 and 2.
<IfModule mod_php7.c>
php_value assert.active 0
</IfModule>
# PHP 8, Apache 1 and 2.
<IfModule mod_php.c>
php_value assert.active 0
</IfModule>
# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
<FilesMatch \.php$>
# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off
</FilesMatch>
</IfModule>
# Set a fallback resource if mod_rewrite is not enabled. This allows Drupal to
# work without clean URLs. This requires Apache version >= 2.2.16. If Drupal is
# not accessed by the top level URL (i.e.: http://example.com/drupal/ instead of
# http://example.com/), the path to index.php will need to be adjusted.
<IfModule !mod_rewrite.c>
FallbackResource /index.php
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^ferienwohnung-koeln\.com$ [NC]
RewriteRule ^(.*)$ http://www.ferienwohnung-koeln.com/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^xn--zimmer-in-kln-smb\.de$ [NC]
RewriteRule ^(.*)$ http://www.ferienwohnung-koeln.com/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^www\.xn--zimmer-in-kln-smb\.de$ [NC]
RewriteRule ^(.*)$ http://www.ferienwohnung-koeln.com/$1 [L,R=301]
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
# Set "protossl" to "s" if we were accessed via https://. This is used later
# if you enable "www." stripping or enforcement, in order to ensure that
# you don't bounce between http and https.
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]
# Make sure Authorization HTTP header is available to PHP
# even when running as CGI or FastCGI.
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# Block access to "hidden" directories whose names begin with a period. This
# includes directories used by version control systems such as Subversion or
# Git to store control files. Files whose names begin with a period, as well
# as the control files used by CVS, are protected by the FilesMatch directive
# above.
#
# NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
# not possible to block access to entire directories from .htaccess because
# <DirectoryMatch> is not allowed here.
#
# If you do not have mod_rewrite installed, you should remove these
# directories from your webroot or otherwise protect them from being
# downloaded.
RewriteRule "/\.|^\.(?!well-known/)" - [F]
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/foo will be redirected to http://www.example.com/foo)
# uncomment the following:
# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/foo will be redirected to http://example.com/foo)
# uncomment the following:
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
RewriteBase /
# Redirect common PHP files to their new locations.
RewriteCond %{REQUEST_URI} ^(.*)?/(install\.php) [OR]
RewriteCond %{REQUEST_URI} ^(.*)?/(rebuild\.php)
RewriteCond %{REQUEST_URI} !core
RewriteRule ^ %1/core/%2 [L,QSA,R=301]
# Rewrite install.php during installation to see if mod_rewrite is working
RewriteRule ^core/install\.php core/install.php?rewrite=ok [QSA,L]
# Pass all requests not referring directly to files in the filesystem to
# index.php.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
# For security reasons, deny access to other PHP files on public sites.
# Note: The following URI conditions are not anchored at the start (^),
# because Drupal may be located in a subdirectory. To further improve
# security, you can replace '!/' with '!^/'.
# Allow access to PHP files in /core (like authorize.php or install.php):
RewriteCond %{REQUEST_URI} !/core/[^/]*\.php$
# Allow access to test-specific PHP files:
RewriteCond %{REQUEST_URI} !/core/modules/system/tests/https?\.php
# Allow access to Statistics module's custom front controller.
# Copy and adapt this rule to directly execute PHP files in contributed or
# custom modules or to run another PHP application in the same directory.
RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics\.php$
# Deny access to any other PHP files that do not match the rules above.
# Specifically, disallow autoload.php from being served directly.
RewriteRule "^(.+/.*|autoload)\.php($|/)" - [F]
# Rules to correctly serve gzip compressed CSS and JS files.
# Requires both mod_rewrite and mod_headers to be enabled.
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
# Serve gzip compressed JS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
# Serve correct content types, and prevent double compression.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1,E=no-brotli:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1,E=no-brotli:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
</IfModule>
# Various header fixes.
<IfModule mod_headers.c>
# Disable content sniffing, since it's an attack vector.
Header always set X-Content-Type-Options nosniff
# Disable Proxy header, since it's an attack vector.
RequestHeader unset Proxy
</IfModule>- Anmelden oder Registrieren um Kommentare zu schreiben
Hallo Bea,ich bin ehrlich
am 12.03.2025 - 18:09 Uhr
Hallo Bea,
ich bin ehrlich gesagt, etwas ratlos wie ich dir helfen soll.
Ich fasse mal kurz zusammen, wie ich deinen Beitrag lese:
.
Von welcher Information in deinem Beitrag soll jemand der das ließt jetzt einen Ansatz ableiten? Das meine ich gar nicht so böse wies klingt. Um dir zu helfen, stelle ich dir deshalb jetzt erst mal ein paar Gegenfragen. Die dienen dem eingrenzen des Problems.
1. Welche Seite kann nicht indexiert werden?
2. von welchem Crawler welcher Suchmaschine?
3. Ist die Datei die du oben gepostet hast aktuell so noch auf eurem Server vorhanden? (Wenn ja, hat Composer sie nicht überschreiben - Die Anpassungen sind ja noch drin).
4. Welche Drupal Version habt ihr den aktuell laut Statusbericht Drupal 10.4.4 oder eine andere?
Richtig ist, ja die .htacess-Datei spielt beim indexieren von Websites eine Rolle. Aber alleine die Aussage deines Webhosters regt mich schon wieder auf. Liegt an der HTACESS -Datei. Und nun? Welche Zeile genau in der .hataccess Datei bzw. welcher Konfigurationsblock da drin soll denn das Crawlen genau verhindern? Wenn dein Webhoster das meint, dann soll er dir doch bitte auch sagen an welchem Teil. So ist dass einfach nur eine Behauptung.
Richtig ist , die Original-Datei aus der Codebasis von Drupal 10.4.4 sieht anders aus als eure. Aber dass kann jeder sehen, der in der Lage ist, den Source-Code des Drupal Core in der aktuellen 10.x aufzurufen.
https://git.drupalcode.org/project/drupal/-/blob/10.4.x/.htaccess
Ich kann dir im Moment nur sagen, das die von dir gepostete .htaccess Datei nicht mal im Ansatz so aussieht, wie die, die Drupal 10.4.4 von Haus aus mitbringt. Mehr Ferndiagnose gestaltet sich aufgrund der fehelenden Angaben als schwierig.
Was sagen denn beispielsweise die Google Webmaster Tools zu dem Crawling Fehler?
Hallo dinmikkith, vielen Dank
am 12.03.2025 - 20:23 Uhr
Hallo dinmikkith,
vielen Dank für Deine ausführliche Antwort.
Meine Seite kann im Moment im Ganzen nicht gecrawled werden.
Alle Seiten werden wohl mit HTTP Statuscode 403 geblocked.
Dies sagt SEOBILITY und auch Google Webmaster Tools.
Drupal habe ich im Moment mit 10.4.3 laufen und mache dann jetzt bei Zeiten das Update auf 10.4.4.
Leider hat der Hoster (WebHostOne) nur gesagt, es liegt an der .httacess Datei und keine weiteren Angaben gemacht.
Ich war ein PingPong Ball zwichen WebHost One und Seobility.
Vielen Dank für den Link auf die aktuelle Drupal 10 .httacess Datei.
Ich werde diese einfach mal gegen meine tauschen und schauen, ob der Fehler immer noch vorliegt.
Bis Juli 2024 lief alles normal, danach ist mir irgendwann dieser Block aufgefallen.
Ich versuche es mal am Wochenende!
Danke!
Super. Wenn dass nicht klappt
am 13.03.2025 - 07:31 Uhr
Super. Wenn dass nicht klappt einfach noch mal melden.
Leider ist es nicht die httacess Datei
am 22.03.2025 - 19:39 Uhr
Hallo zusammen,
ich habe die alte Datei nun gegen die neue httacess Datei ausgetauscht und leider wirft die Seite immer noch den gleichen Fehler aus.
----> HTTP Statuscode 403
Ziemlich frustrierend, da mir irgendwie niemand sagen kann, woran das liegt.
Seobility verweist an Webhost One und die wollten mal wieder die IP Adresse des Crawlers haben, um den Fehler in den LogFiles zu suchen.
Wobei die Google Search Console auch geblockt wird.
Hat jemand eine Idee, warum die Drupal Installation die Crawler und sogar die Indexierung blockiert?
Danke!
Um das herauszufinden müsste
am 23.03.2025 - 12:23 Uhr
Um das herauszufinden müsste man sich die Seite von innen ansehen. Die Frage ist, ob du das Modul robots.txt installiert hast oder einen der hier genannten tags gesetzt hast.
https://developer.chrome.com/docs/lighthouse/seo/is-crawlable?hl=de#:~:t....
Eventuell hast du auch das Metatag noindex=all über ein Drupal-Modul gesetzt.
Du musst es halt rausfinden. Dass kann nur jemand, der sich die Seite von innen ansehen kann.
Hier ist, was ich von aussen herausgefunden habe:
1. Die Seite ist teilweisexindexiert:
2. Du hast mixed content auf deiner Seite, der teilweise über http geladen wird. Das gilt vor allem für deine Bilder.
Aber die Seite kann gecrawled werden.
Beispiel: https://search.google.com/test/rich-results/result?id=zxbYTIXoaWNst9FJWb...
Hast du mal eine url für die du eine 403 Meldung zurück bekommst, bitte?
Hallo zusammen, das Crawling
am 28.03.2025 - 19:49 Uhr
Hallo zusammen,
das Crawling Problem ist gelöst!
Entgegen von bestimmt 5 Aussagen von WebhostOne wurde der Crawler von Seobility dann doch geblockt, will die die IP auf die Blacklist gesetzt hatten!!!
Eine Unverschämtheit, weil sie es erst verneint hatten und mich auf die httaccess Datei verwiesen hatten.
Die war es dann aber doch nicht.
Das Crawling funktioniert wohl nun endlich wieder und ich hoffe ich bekomme die Seite auch irgendwann mal in den Griff.
Ich habe einfach kaum Zeit, wie man vielleicht anhand der Internetseite ableiten kann.
Ich habe nun die alte httaccess Datei wieder hochgeladen und werde mich um Deine guten Hinweise bezüglich des Mixed Contents kümmern müssen.
Erstmal danke!
Frage: Bist Du selbständig tätig und kannst Drupal Seiten verbessern?
Danke!
Ich kann das nur das mit der
am 28.03.2025 - 20:50 Uhr
Ich kann das nur das mit der Zeit ist das bei mir ähnlich.
Ich kann das nur das mit der
am 28.03.2025 - 20:50 Uhr
Ich kann das nur das mit der Zeit ist das bei mir ähnlich.