BugWP logo BugWP
Back to Community
Home / Community / Core → Developing with wordpress

How to Fix Access-Control-Allow-Origin Errors for Multilingual WordPress Sites

23 threads Sep 16, 2025 Core → Developing with wordpress

Content

If you're running a multilingual WordPress site using subdomains (like de.yoursite.com and en.yoursite.com), you might encounter a frustrating issue where resources like fonts, stylesheets, or scripts fail to load on one of your language versions. The browser's console will often show an error related to the Access-Control-Allow-Origin header. This guide will explain why this happens and provide the correct solutions.

Why Does This Error Occur?

This is a security feature enforced by web browsers known as CORS (Cross-Origin Resource Sharing). By default, a web page from one domain (e.g., de.yoursite.com) is not permitted to access resources on another domain (e.g., yoursite.com). The server must explicitly grant permission by sending the correct Access-Control-Allow-Origin header.

A common mistake, as seen in the support threads, is to define the header multiple times in the .htaccess file. The following configuration is incorrect because the second header directive will overwrite the first, making it only effective for the English subdomain:

# ❌ INCORRECT: This will not work for both domains
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "https://de.test.sacconicase.com"
</IfModule>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "https://en.test.sacconicase.com"
</IfModule>

Solution 1: Specify Multiple Origins in a Single Header (Advanced)

The official way to solve this is to configure your server to dynamically allow multiple origins. This typically requires access to your server's main configuration (e.g., Apache's httpd.conf or a virtual host file) and knowledge of the mod_setenvif module. It is complex and often requires a system administrator's help.

Solution 2: The Wildcard Method (Use with Caution)

A simpler, but less secure, alternative is to use a wildcard (*) to allow all domains. This is quick but should only be used on development/staging sites or if you are absolutely sure you will not be serving any private user data from the resources being shared.

# ⚠️ Use wildcard only if security is not a concern
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>

Solution 3: The Recommended WordPress Approach

For most users, the best and most secure solution is to avoid the cross-origin request altogether. Instead of having your subdomains pull resources from your main domain, you should serve all assets (CSS, JS, fonts) directly from each subdomain.

This often means ensuring your WordPress site is configured correctly to handle subdomains. Key steps include:

  • Defining WP_SITEURL and WP_HOME: Use conditional code in your wp-config.php file to dynamically set the site URL based on the subdomain, ensuring all generated links point to the correct origin.
// Example wp-config.php snippet for subdomains
define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] );
define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] );

if ('de.' == substr( $_SERVER['HTTP_HOST'], 0, 3 )) {
   define ('WPLANG', 'de_DE');
}
if ('en.' == substr( $_SERVER['HTTP_HOST'], 0, 3 )) {
   define ('WPLANG', 'en_EN');
}
  • Using a CDN: Serve your static assets from a Content Delivery Network (CDN). The CDN's domain becomes the single origin for your files, eliminating the cross-origin issue between your own subdomains.
  • Checking Plugin Settings: Some optimization or asset-handling plugins have settings to help with domain handling for CDNs or multilingual setups.

Conclusion

The Access-Control-Allow-Origin error is a common hurdle when setting up a custom multilingual WordPress installation. While tweaking .htaccess is a natural first thought, the most robust and secure solution is to architect your site so that each subdomain is self-contained or uses a neutral third party (a CDN) for shared resources. Always avoid the wildcard method on production sites handling sensitive data.

Related Support Threads Support