Problem/Motivation
Drupal Core provides a robots.txt file that dissalows /search/.
Please note the trailing slash in that entry.
Link to source: https://git.drupalcode.org/project/drupal/-/blob/11.x/robots.txt?ref_typ...
Drupal sites often don't rely in core search but in custom views with filters or search_api views and facets.
Most of the times these use http query arguments, in the form of /search?title=robots.
Please note the absence of a trailing slash, the word search is followed by the arguments (?)
The current Drupal Core robots.txt rules do not apply for /search?
This creates a scenario where bots/crawlers, bad or legitimate like Googlebot and Bingbot will start indexing all search pages, creating a bad index and, in the case of facets, also causing server performance issues as they try to follow any possible combination of faceted search pages.
Steps to reproduce
- Install Drupal
- Create a search_api faceted search
- Submit site to google
- See crawl logs and see googlebot index faceted pages
- See it trying every possible combination, an endless situation
Proposed resolution
All of this can be easily fixed for all sites by changing:
Disallow: /search/
to
Disallow: /search/
Disallow: /search?
See https://developers.google.com/search/docs/crawling-indexing/robots/robot... for details and info on what led to this suggestion.
Remaining tasks
Fix the line in robots.txt, both in drupal root and scaffold files folder.
Release notes snippet
The default robots.txt file now blocks search result pages with query parameters from being crawled by search engines. Previously, only path-based search URLs (like /search/keyword) were blocked, but query parameter searches (like /search?q=keyword) remained accessible to crawlers. This caused search engines to index dynamically generated search results and crawl infinite combinations of faceted search pages, degrading site performance and SEO quality.
Site owners who have customized their robots.txt file should consider manually adding these rules:
Disallow: /search?
Disallow: /index.php/search?
This change only affects new installations and sites using the default scaffold robots.txt. Existing custom robots.txt files will not be automatically updated. See the change record (draft, not published) for more information.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3550083
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
bserem commentedComment #4
bserem commentedComment #7
smustgrave commentedMRs should point to 11.x and should be one MR please.
May want to add an additional entry but not sure we should remove the existing. Temped to tag for framework manager sign off.
Comment #8
markconroy commentedThanks for working on this @bserem. I've seen a lot of LocalGov Drupal sites getting hammered because of crawlers following all facets pages.
I think this issue/MR would definitely qualify as a "Needs framework manager signoff" issue.
Comment #10
bserem commentedThanks for the pointers @smustgrave
Having an extra entry is also an option, I opted against it for less repetition, as the current change achieves the same results.
Putting back to needs review.
Comment #11
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #12
bserem commentedRecreated the branch and the MR to not include any 11.2.x stuff as advised in #7 above.
The diff is now clean. Marking as needs review again.
Comment #13
smustgrave commentedComment #14
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #15
nod_Comment #16
bserem commentedComment #17
ifrikThis works, and it solves the issue. Core's search pages use the path /search/node and /search/user so the trailing / make sense, but other search pages (for example when building a search view using Search API) often just use /search.
Since the core search paths are still covered by this change, it's a simple change that will benefit other setups as well.
Comment #18
poker10 commentedThanks for working on this.
I think that the proposed change can cause issues on some sites. As per https://developers.google.com/search/docs/crawling-indexing/robots/robot... , the
Disallow: /searchwill match anything starting with /search, so it has a potential to also block any content with URL alias starting with that string (for example a news with an alias of /search-for-donations, etc.). Based on this, moving back to NW.Also this is probably more like a Feature request than a Bug, given there is no issue with the core itself.
Comment #19
bserem commentedComment #20
bserem commentedComment #21
bserem commentedComment #22
bserem commentedI've only now realized that comments submitted in gitlab might not be visible here according to user settings. Work has been done in https://git.drupalcode.org/project/drupal/-/merge_requests/13399#note_60... and screenshots have been added in that comment to visualize the changes.
Quoting gitlab comment here, without screenshots, for clarity:
Comment #23
bserem commentedComment #24
smustgrave commentedBelieve feedback has been addressed.
Comment #25
catchThis is a good idea but it needs a change record and release notes snippet since it's changing site owner managed/scaffolded files.
Comment #26
bserem commentedMade a change record: https://www.drupal.org/node/3567198
Added "Release notes snippet".
Full transparency: as English is not my first language I did use an LLM to improve my writing to something more formal.
Moving this back to RTBC, I hope I this is the right place.
Comment #27
bserem commentedCleaning up tags.
I also feel "needs framework manager review" can go since @smustgrave and @catch have checked this.
Comment #29
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #30
smustgrave commentedBot rebellion
Comment #35
godotislateRemoved the "Needs framework manager review" tag since @catch approved in #25.
Committed a38ee74 and pushed to main and committed 519d5d6 and pushed to 11.x. Thanks!
Comment #37
longwaveChanges to user managed files should be called out in the release notes.