301 Redirect

This happened today at 4:50pm and 8:50pm. NGINX wasn’t the problem, I deactivated Memecache now to see it that’s what is causing it.

Happened again this morning, I now have Dynamic Caching turned off to try to fix the issue.

• This reply was modified 3 years, 9 months ago by stinamariechris.

The redirect loop hasn’t come back since I turned off Dynamic Caching. I’d like to use Dynamic Caching as it greatly increases my site speed. Any ideas on how to remedy the redirect loop?

As I already explained on Facebook, this is a problem for your developer. Your pages have those parameters in your database. I am not sure why this is happening because we could not recreate it on our end but this is definitelly not a SG Optimizer or caching problem. You have mixed functional and tracking parameters too, we ignore the tracking parameters when we cache but not the functional ones. That’s probably why you only see that redirect. I

Did this issue get resolved?

We are experiencing the same problem which only started after being migrated to NGINX. The response from support seems too vague to be actionable. Because the new Caching method does not use Vary:User-Agent, I believe this may be a factor in these new caching issues. I am trying to determine which functional tracking parameters they are referring too (i.e. PHPSESSID or Cookies)?

I am not sure how anyone can say it is not our problem because they cannot recreate it, especially when it directly correlates to the migration to NGINX and caching changes?

@juhl Yes and no. My issue was with Hubspot’s tracking parameters in Google Ads. I’ve removed all instances of those parameters from Google Ads and the issue was fixed. This issue started happening a few weeks after my website was migrated to Sitetools, I’ve been using those same tracking parameters for years with no issues. I do not know what functional cookies they were referring to.

@stinamariechris After looking at it further I believe they are referring too fbclid and gclid or other “functional” tracking codes, not the PHPSESSID/cookies? So including a Hubspot tracking ID in your UTM parameters (i.e. Hubspot visitorID) vs relying on tracking pixels to show visitor attribution specific information based on cookies.

I have other tracking codes that include Google gclid but the one that is always involved with an issue is actually a Facebook UTM code. Facebook does have a much larger clid ID (206 characters) than Google (97 characters) but I’m not sure that is a factor.

@juhl I’m using gclid and fbclid with no issues now. I put my own UTM parameters on my Facebook and Google Ads as well after I removed the Hubspot tracking URL (basically just utm_source=google&utm_medium=cpc&utm_campaign=GAW-SingleKeyword). I’m curious, what’s your Facebook URL that the website is redirecting to?

I had Hubspot tracking also on my Facebook ads, which I removed, but didn’t have any issues with it. My issues were only with the Google Ads tracking URLs, which happens to use {keyword} and ads a lot of spaces to the URL, vs Facebook which didn’t.

@stinamariechris Our FB campaign (below) also has a lot more spaces than Google campaigns hitting the site. So if we rule out gclid and fbclid and your fix was removing keyword due to spaces in the UTM parameters that would seem to narrow down the potential cause to either URL length or spaces although does not answer the why? Especially since per SG they “ignore” tracking parameters.

I wonder if we change to dashes vs. spaces that would potentially fix the issue? I cannot ask the Ad agencies to remove or change how they track campaigns because it is not an issue on WPEngine. Ultimately we may need to just change hosting providers to fix “our problem”.

&utm_campaign=HLMS%20-%20No%20Program%20-%20Traffic%20-%20On%20Going%20Nurturting
&utm_term=HLMS%20-%20On%20Going%20Nurturing%20-%20Allied%20Health%20and%20Cosmo

@juhl I don’t think it’s character length because my Facebook url was just as long as my Google Ads and I didn’t have the issue with Facebook. Any URL that converted spaces to %20 had the issue. It was the only similarities I could find. Do you think you could do a test and remove all spaces from your URLs and replace with dashes?

@stinamariechris I doubt I can do that against live (reenabling Dynamic Cache) since we have had 5 outages with this redirect loop issue. We cannot reproduce the error in staging which makes it very hard to find a fix without a potential impact to production.

I do see a correlation but would really like SG to confirm and provide a potential reason.

@juhl I don’t blame you. I went out about 3 times a day for a week and I wouldn’t want to test on the live site again, either. It’s our busy season and not worth the risk. I hope Siteground can confirm.

@hristo-sg Can you please read back through this thread and our shared experiences with this issue? If SG ignores everything in the UTM then functional or tracking parameters would both be ignored? We still do not understand what you are referring too as functional parameters since everything is passed within the UTM code.

@juhl @stinamariechris @hristo-sg Hi everyone! Any update on this? We’ve been having the same issue since mid-February. We disconnected HubSpot and Google Ads, which solved that particular redirect loop. However, we are now getting redirect errors related to our HubSpot campaigns. Issue is temporarily resolved when we clear the dynamic cache in SiteGround.

I’ve disabled NGINX caching, and placed the proper rule in our .htaccess file to disable dynamic caching. However, the site continues to crash due to the redirects. Any insight is greatly appreciated!

@hristo-sg @stinamariechris @sageallott

The only work around we found is to install the SG Optimizer plugin and disable Dynamic Cache and memchached in the plugin. We use WP Rocket for speed optimizations vs the SG Plugin, so all other features are disabled as well.

Since SiteGround will not acknowledge this issue we are moving to WP Engine for hosting.