I was advised to post here from Stack Overflow

We need help. We're running an ad campaign and realized that a lot of paid traffic was landing on a 404 not found page.

The issue is caused by auto-tagging in Google Ads when it appends a gclid parameter to the query string. Google Ads has the option to disable auto-tagging but there is no such option in Facebook. Traffic from Facebook lands on a 404 not found page every time. We inherited the site that was built on Joomla 3.10.0

Here's what happens:

  • We specify the link we want to promote, e.g. https://www.example.com
  • Google & Facebook append their parameters, e.g. ?fbclid=IwAR1m3AFCDb2Ouiickaw3lk4CqMCbfgf0wc-JX-08WTddIw0CCw7iyCoLs2g

Then, something weird happens with the redirection. The server access logs show the request getting redirected from:




NOTE: example.com/www.example.com/



We think it's related to Joomla's rewriting system but aren't familiar with it enough to know how to fix it. It's also possible that we have a misconfiguration in the .htaccess file.

We have Search Engine Friendly URLs enabled. We have Use URL Rewriting enabled.

The site is in the /public_html/ folder. We've tried commenting out different parts of the .htaccess but nothing worked. We normally use WordPress and have limited knowledge of Joomla and/or .htaccess files.

One final note: normal, readable query parameters don't seem to cause this issue because our manual UTMs work fine. Something about the fbclid/gclid strings in particular may be related... that's just a guess.

Here's a copy of our .htaccess:

# @package    Joomla
# @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license    GNU General Public License version 2 or later; see LICENSE.txt

## No directory listings
<IfModule mod_autoindex.c>
  IndexIgnore *

## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
# Disable Federated Learning of Cohorts (FLoC)
# If you uncomment the below directive you have to allow this technology in the 
# Global Configuration of Joomla. Read more about this in the Post-Installation 
# message in the backend.
# Header always set Permissions-Policy "interest-cohort=()"

Options +FollowSymlinks
Options -Indexes

## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
  <IfModule mod_headers.c>
    Header always set Content-Security-Policy "script-src 'none'"

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
<IfModule mod_rewrite.c>
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
## End - Custom redirects

# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).

RewriteBase /

## Begin - Joomla! core SEF Section.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
## End - Joomla! core SEF Section.

Thanks for any insight you can provide.

  • Welcome to JSE. I, for one, have absolutely no problems with crossposting. I do like to see Joomla content stockpiled here though. If someone offers anything valuable at SO, I would like to see that it is transferred here (where it belongs). I mean, why have a Stack Exchange community dedicated to supporting Joomla questions if the content is going to be shared in two locations (not to mention sharing with Joomla Forum). Commented Nov 12, 2021 at 6:21
  • Thanks @mickmackusa. Long time lurker, first (second?) time poster haha. I was more than happy to share any solution across platforms but, well, mods deleted the other one so chances of this getting resolved seem significantly smaller now. That's not to disrespect to this stack... it's just the difference in community sizes. And I'm still not convinced this issue is specific to Joomla. Other platforms have had similar problems.
    – phvntom
    Commented Nov 12, 2021 at 16:39
  • I was surprised to learn that it is by popular opinion (Is cross-posting a question on multiple Stack Exchange sites permitted if the question is on-topic for each site? ) that crossposting is frowned upon and I spoke with a SO moderator yesterday who said that they will instantly delete any crossposted content from SO if they are notified that the post is duplicated elsewhere in the Stack Exchange network. Commented Nov 12, 2021 at 21:54
  • For anyone who wants to see the rule against crossposting changed, vote here: Dissonance between allowing signposts and forbidding crossposts Commented Nov 13, 2021 at 23:08

1 Answer 1


We discovered that a backup from a few months ago didn't demonstrate the problem... A lot of changes have been made since then. Some extensions had been updated, as well as Joomla itself.

We tried replacing only the .htaccess and configuration.php files but those didn't fix it.

The changes we cared about most were stored in the database, so we re-uploaded the filesystem from the backup and preserved the data. Problem solved.

Unfortunately, I can't comment on why this was happening or what specifically fixed it. There was errant code somewhere.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.