[Resolved] Split: after the hosting change, some redirects don't work:

How did you set up those redirects? What happens if you temporarily remove all your custom redirects?

Are you using the standard WooCommerce functionality for this?
Also, please check whether the option “Redirect to the cart page after successful addition” is disabled under WooCommerce → Settings → Products → Add to cart behaviour.

Thank you for your feedback.

I need to request temporary access (wp-admin and FTP) to your site—preferably to a test site where the problem has been replicated if possible—in order to be of better help. When you log in to leave your next reply, you will find the needed fields below the comment area. The information you will enter is private, meaning only you and I can see and access it.

Yes, sure. The following message is set to private.

I ran a few tests. In Incognito mode, the redirect doesn’t occur. This suggests that the product isn’t being added to the cart, so any redirect that depends on a successful “add to cart” never fires.

Please try the steps below:

1) Clear caching
• Purge server/CDN cache and any caching plugin.
• Exclude WooCommerce endpoints from caching: /cart/, /checkout/, ?add-to-cart=, and /?wc-ajax=add_to_cart.

2) Create a test product (SK)
• Add a simple test product in the SK language (price, stock, published).
• Try adding it to the cart on the SK site.

3) Enable debugging and check logs

Edit wp-config.php (before the line “/* That’s all, stop editing! Happy publishing. */”):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

• Reproduce the issue, then check /wp-content/debug.log for errors.
• Also check WooCommerce → Status → Logs for today’s logs (look for “fatal-error” or AJAX/add-to-cart entries).

4) Quick sanity checks
• WooCommerce → Settings → Products → General: if relevant, test with “Enable AJAX add to cart buttons on archives” on/off.
• Security/CDN/WAF: make sure POST requests to /?wc-ajax=add_to_cart aren’t blocked.

5) Fix database collation (prevents related issues)

Your tables still show latin1_swedish_ci. Please convert the database and all tables (including WPML icl_*) to:
• Charset: utf8mb4
• Collation: utf8mb4_unicode_520_ci (or utf8mb4_unicode_ci if 520 isn’t available)

This avoids character corruption and can eliminate odd failures around localized data.

6) If problems started after the host change

Since the previous host worked fine, consider re-migrating with the correct encoding/collation from the start (export/import as utf8mb4).

Yes, that is indeed strange.

I still recommend going through all the steps I shared earlier and letting me know the results. I’m confident this will bring us closer to a solution.