CDN Strategy for Multilingual Websites: Edge Delivery, Vary Header, Geo-Routing

Basics of Multilingual Delivery in the CDN

A CDN (Content Delivery Network) accelerates the delivery of your website by distributing static and dynamic content to edge servers in different regions. For multilingual websites, however, you must ensure that each user receives the correct language version – regardless of their location. The basic idea is that the CDN selects the language version based on signals such as the browser's Accept-Language header, IP geolocation, or a cookie preference, and delivers the correct version from the cache or retrieves it from the origin server.

In practice, you should first clearly identify your language versions. Use either different URL paths (e.g., example.com/de/), subdomains (de.example.com), or a country-specific domain (example.de). The CDN must account for this distinction in the cache key, so that different language versions are not incorrectly treated as the same content. Therefore, configure a cache key in the CDN that includes both the URL and the language or path. Many CDNs allow you to specify a custom cache key, for example by including the Accept-Language header.

A common challenge is dynamic language selection. If your website determines the language server-side based on cookies or session data, you must ensure that the CDN understands this dependency. Otherwise, a user might receive the version intended for a previous visitor. It is recommended to encode the language in the URL, as URLs are easiest to cache. If you use geo-routing, combine it with a fallback mechanism for users who prefer a different language.

Recommended actions: Choose a consistent URL structure per language and configure the CDN cache key to include language information (e.g., via path or header). Test the behavior with different browser settings to ensure the correct version is delivered. Document your configuration to avoid future errors.

How Edge Delivery Works for Language Versions

Edge delivery means that content is served directly from the geographically nearest edge servers without burdening the origin server. For multilingual websites, these edge servers must be able to correctly identify and deliver the requested language version. The idea is to move the language selection process as close to the user as possible – either via server-side logic within the CDN or through pre-generated static files per language.

In practice, it is recommended to generate separate static files for each language version and cache them on the edge servers. Your origin server creates the HTML pages for each language (e.g., via a build tool) and uploads them to the CDN. The edge server can then deliver the correct file based on the URL path or a cookie preference. No backend call is required, drastically reducing latency. This method is especially suitable for websites with predominantly static content, such as corporate sites or blogs.

Another variant is dynamic edge delivery, where the CDN makes language selection based on the Accept-Language header. This requires an edge function (e.g., Cloudflare Workers, Lambda@Edge) that evaluates the header and loads the corresponding version. This allows customized delivery but requires more configuration and can impact cache hit rates, as different headers lead to different cache entries. Combine dynamic logic with a careful cache key strategy.

Recommended actions: Whenever possible, use static pre-generation per language and store the files in the CDN. If dynamic logic is necessary, implement an edge function that evaluates the Accept-Language header and loads the appropriate file. Set realistic cache durations and test latency with tools like WebPageTest to ensure fast delivery in all regions.

HTTP Vary Header: Configuration and Pitfalls

The HTTP Vary header is essential for multilingual websites because it tells the CDN and browsers which request headers affect the response content. Without correct Vary configuration, a language version might be delivered to a user even though they requested a different language. The Vary header prevents the CDN from incorrectly serving a cached response for one language to users with another language preference.

Set the Vary header to at least "Accept-Language" if your website selects language based on this header. Example: "Vary: Accept-Language". If cookies or other headers are also relevant, list them as well—separated by commas. However, note that an overly broad Vary configuration can reduce cache efficiency, as the CDN must store different versions for each combination of specified headers. In practice, it has proven effective to specify only the truly relevant headers and, where possible, move language selection to the URL to minimize Vary usage.

A common pitfall is using "Vary: User-Agent" for language selection—this is usually incorrect and drastically reduces cache hit rates. Omitting Vary altogether can lead to inconsistent deliveries. Another mistake is setting the Vary header only on the origin server but not in the CDN. Many CDNs respect the origin's Vary header, but you should explicitly check this in the configuration. Use tools like "curl -I" to verify the header is sent correctly.

Action recommendations: Always set the Vary header on the origin server to "Accept-Language" (or extend it as needed). Check your CDN's cache key configuration—it should respect the Vary header, otherwise the header is ineffective. Test with different Accept-Language values to ensure the correct version is delivered. Avoid unnecessary Vary values that impair cache performance. For legal aspects of language selection (e.g., mandatory legal notice), please consult a lawyer.

Geo-Routing and DNS-Based Language Control

Geo-routing directs visitors to the nearest data center or edge server based on their IP address. This reduces latency by delivering content from a geographically close location. For multilingual websites, the question arises whether geo-routing should also be used for language control. In practice, this is not recommended because geographic location alone does not reliably determine language. In multilingual countries such as Switzerland, Belgium, or Canada, users speak different languages. Pure geo-routing would always deliver the same language there, regardless of individual preferences.

Instead, you should primarily use geo-routing for performance optimization. Configure your CDN so that all language versions are delivered via the same distribution, but edge servers are selected based on user location. Language selection then occurs at the edge level through other mechanisms (e.g., Accept-Language header, cookie, or URL path). DNS-based geo-routing services like AWS Route53 with geolocation routing can be used to route users from specific regions to different CDN endpoints. However, this is only sensible if you operate separate origins for different regions—for example, to comply with legal requirements or offer local content. For pure language control, this approach is too inflexible.

A proven configuration is to use a single CDN record (e.g., CNAME to a CloudFront distribution) for all language versions and limit geo-routing at the DNS level to latency optimization (latency-based routing). The decision of which language version to deliver is made at the edge—either through an edge function that evaluates the Accept-Language header or through the URL structure (e.g., /de/ or /en/). Avoid assigning users to a specific language version solely based on their IP, as this leads to frustration and impairs the user experience.

In summary: Use geo-routing only for edge server location selection, not for language selection. Combine it with language detection logic on the edge server or URL-based language control. This ensures content is delivered quickly and the correct language version is available for each user. For DNS-based control, a service that supports both latency and geolocation routing is recommended if specific regional requirements exist.

Caching Strategies for Dynamic and Static Content

Multilingual websites combine static content (such as translations, images, CSS) with dynamic content (personalized elements, shopping cart). Each component requires a tailored caching strategy to minimize load times and ensure freshness. Static assets should be given a long cache duration as they rarely change. Use versioning in filenames (e.g., style.v2.css) and set the Cache-Control header to max-age=31536000 (one year). This enables aggressive caching at the CDN and browser level without requiring full invalidation upon updates.

For HTML pages that differ per language, a URL-based language identifier (e.g., /de/produkt) is recommended. The cache key automatically includes the language, so the CDN stores separate copies for each language version. Set a moderate cache duration (e.g., 10–60 minutes) for these pages, depending on update frequency. Use CDN purge mechanisms to selectively invalidate language versions when content changes. Avoid using the Accept-Language header in the cache key (via Vary), as it reduces cache hit rates. Instead, use the URL or a cookie that you incorporate into the cache key using an Edge Function.

Dynamic content such as personalized greetings or shopping cart data cannot be cached via the CDN. Here, using ESI (Edge Side Includes) or offloading these elements to asynchronous API calls is appropriate. Many CDNs support ESI to dynamically assemble personalized fragments while the rest of the page comes from cache. Alternatively, you can load these parts via client-side JavaScript. Another option is to use dynamic acceleration services that provide specific optimizations for non-cacheable content.

In practice, the following combination has proven effective: static assets with long cache duration and versioning; HTML pages with URL-based language version and moderate TTL; dynamic elements via ESI or async loading routines. Avoid using cookies for language selection if you want to cache the entire page — unless your CDN allows incorporating the cookie value into the cache key. Regularly test caching behavior with appropriate tools to ensure users always receive the latest language version without performance losses.

Language Detection at the Edge: Header, Cookie, URL Path

To deliver the correct language version to visitors, the CDN must determine the desired language. Three established methods exist: evaluating the Accept-Language header, a language cookie, or the URL structure (path or subdomain). Each method has advantages and disadvantages, particularly regarding caching and SEO. The URL path (e.g., /de/startseite) is most cache-friendly because the CDN stores each URL as a separate entry and no Vary header is needed. The downside: the user must explicitly select the language or be redirected by the server.

The Accept-Language header allows automatic detection without a cookie. However, using the Vary header (Accept-Language) in the CDN often leads to cache fragmentation, as each header value generates its own cache copy. Many CDNs support Vary only limitedly or ignore it entirely. Therefore, it is recommended to use the header only for initial language detection and then redirect the user to a URL with a language path. This can be done via an Edge Function that reads the header, optionally sets a cookie, and performs a 302 redirect to /xx/.

A cookie provides persistent storage of the language preference, even across sessions. For CDNs that support a custom cache key based on cookies, this can be a solution. The cache key then contains the cookie value, so different languages are cached separately. The downside: first-time visitors without a cookie must receive a default language (e.g., via Accept-Language), and the cache for visitors with a cookie is less efficient because many different cookie values exist. Hence, this method is more suitable for websites with few languages or when personalized language control is unavoidable.

Our recommendation for practice: Use the URL path as the primary language identifier. Deploy an Edge Function (e.g., Lambda@Edge or CloudFront Functions) that evaluates the Accept-Language header when no language path is present and redirects the user to the appropriate language URL. Optionally, set a cookie to skip manual selection on future visits. This combination is cache-friendly, SEO-compliant (clearly separated URLs), and provides good user experience. Ensure that the redirect is short-lived or not cached at all, so it works correctly when language changes occur.

Handling Multilingual SEO and hreflang Tags

Hreflang tags are the primary signal for search engines to communicate the linguistic and regional targeting of your pages. In a CDN environment, you must ensure that these tags are correctly present on every delivered page. The most common methods are: - Embedding in the HTML <header> via <link rel="alternate"> elements - Setting the HTTP Link header (e.g., Link: <https://example.com/de/>; rel="alternate"; hreflang="de") - Specification in the XML sitemap

Each variant has its pros and cons: The HTML approach is easy to implement but may not be fully adopted by some CDN caching layers when the page is dynamically generated. The HTTP header is more robust as it can be evaluated by the CDN independently of the HTML body. The sitemap serves discovery, not page-level signaling – it alone is insufficient. We recommend setting hreflang both in HTML and as an HTTP header to safeguard against cache loss.

A common mistake is the absence of self-referencing tags – every URL must include an hreflang entry for itself. Additionally, use the correct language code according to ISO 639-1 and, for regional variants (e.g., de-AT), observe the two-part structure. Ensure that your CDN does not strip the hreflang headers from the response packet. Test with the Google Hreflang Test Tool or via Search Console to verify that all language variants are correctly recognized. A centralized configuration via an edge worker that dynamically adds hreflang headers based on the requested URL is a reliable solution in practice.

Action recommendation: Conduct regular monitoring of hreflang signals, e.g., using crawling tools that examine your CDN’s output. Document your configuration in an internal playbook to prevent gaps during CDN switches or cache events. Note that hreflang is not a direct ranking signal but supports correct indexing of language versions.

Protecting Against Incorrect Geolocation

Geolocation via IP address is error-prone: users with VPN, proxy, or mobile data sources may receive the wrong language version. Even CDN-owned geo databases can be outdated or inaccurate. The result is an increased bounce rate when visitors see the wrong language. Therefore, a multi-layered safeguard is advisable.

A proven approach is to use geolocation only as an initial suggestion and always allow the user to manually switch. Additional signals such as the browser’s Accept-Language header or stored cookie preferences should always take precedence over Geo-IP. In your CDN configuration, you can employ edge workers to evaluate these signals: for example, a worker first checks an existing language cookie, then the Accept-Language header, and finally Geo-IP. Only if none of this information yields a clear language is Geo-IP used.

Another issue is cache isolation: if you serve different language versions on the same URL (e.g., via geo-routing without URL path), cache poisoning can occur – a user from Germany suddenly sees the English version because the cache for the base URL was previously populated by a US visitor. Avoid this by either making language part of the URL (e.g., /de/) or a query parameter, and set the Vary header accordingly. However, Vary: Accept-Language is problematic in practice because the header has many variants and cache hit rates decrease. Better: Vary: Cookie with a language cookie or Vary: X-Language for custom headers.

Action recommendation: Offer a visible language switcher on every page and store the selection in a cookie for at least 24 hours. Regularly test your geo logic with a simulated proxy from different regions – use CDN-internal tests or external providers. Document the decision cascade (Cookie > Header > Geo) in your codebase to ensure it remains intact during updates.

Performance Metrics: Latency, Byte Transfer, Cache Hit Rate

To evaluate the effectiveness of your CDN strategy, three metrics are central: latency, bytes transferred, and cache hit rate. These should be captured both globally and per language version, as differences in content volume or regional CDN pop deployment may occur.

Latency: Measure the time to first byte (TTFB) and total load time. For multilingual sites, latency is particularly critical for dynamic language switching (e.g., via geo-routing). Use Real User Monitoring (RUM) to collect values from actual user behavior – perception from different regions is key. Pay attention to P95 and P99 values to identify outliers. Reduce latency through prefetching of language resources and persistent connections to the origin.

Bytes Transferred: Depending on the language version, pages can vary in size – for example, due to longer translations or different fonts. Optimize via CDN compression (Brotli or Gzip) and minimize outgoing data by server-side reduction of whitespace and metadata. Provider billing often depends on data volume served; a 20% reduction can noticeably lower costs. Compare byte counts of different language versions monthly and check whether CDN caching at the edge level applies equally for all languages.

Cache Hit Rate: A high hit rate (ideally above 90%) relieves the origin server and reduces response times. Multilingual pages complicate caching if each language version runs on its own URL with its own caching rules. Use consistent cache keys that correctly map language and region. Monitor whether certain language versions frequently bypass the CDN to access the origin – this may indicate missing caching headers or too many individual parameters. Increase cache duration for static assets that are language-independent (e.g., JavaScript libraries) and use a cache-busting mechanism when changes occur.

Action Recommendation: Set up a dashboard with these three metrics per language version. Define warning thresholds (e.g., TTFB > 500 ms for dynamic pages, cache hit rate < 85%). Conduct regular A/B tests where you vary caching rules or compression to improve performance. Document the results and iteratively adjust your CDN configuration.

Legal Aspects: GDPR-Compliant Localization at the Edge

Localizing content at the edge involves processing personal data, such as IP addresses for geolocation. According to the GDPR, this processing is only permissible with a legal basis. In practice, you should limit geolocation to what is necessary – for example, the regional level (e.g., federal state) is often sufficient to determine the language without having to store the exact address. We recommend processing IP data only in the memory of the CDN edge server and not logging or sharing it with third parties.

A common pitfall: storing user preferences via cookies. Use cookies that require consent for this purpose. Alternatively, use server-side cookies without tracking characteristics or URL paths (e.g., /de/). Ensure that the language choice is not merged with other data (e.g., analytics) unless the user has actively consented. When using geo-routing, IP addresses are temporarily evaluated – according to many supervisory authorities, there is a legitimate interest (Art. 6(1)(f) GDPR). Document this balancing of interests.

Practical Implementation: Configure your CDN so that geolocation occurs without IP logging. Use short-lived caches (e.g., 5 minutes) for the region-to-language mapping. When processing data with the CDN provider, conclude a Data Processing Agreement (DPA). Check whether the CDN provider has server locations in the EU to avoid data transfers. For language delivery at the edge, consent is generally not required if you do not create profiles. However, seek legal advice to review the specific configuration of your setup.

Future Developments: The ePrivacy Regulation draft could introduce stricter rules for processing metadata. Therefore, plan for maximum data minimization from the outset. Regularly check whether your CDN provider offers GDPR-compliant localization features (e.g., edge workers with data minimization). A yearly Data Protection Impact Assessment (DPIA) for the localization component is recommended.

Implementing a Multi-CDN Approach for Redundancy

A multi-CDN approach distributes the delivery of your multilingual content across several content delivery networks. This increases fault tolerance and can improve latency if a CDN fails regionally. In practice, this means using two or three CDN providers in parallel, either via a traffic distributor (e.g., DNS-based) or a failover strategy. For multilingual websites, this is especially relevant because language versions may perform differently depending on the region.

Concrete implementation: Select CDN providers with complementary edge locations (e.g., cloud provider A with a strong presence in Western Europe, provider B in Eastern Europe). Configure DNS routing (e.g., via Anycast or GeoDNS) so that requests go to the optimal CDN depending on the region. Alternatively, use an application load balancer that forwards requests based on latency measurements. Important: All CDNs must serve the same origin content and deliver the language versions uniformly. Ensure synchronized cache configuration (Vary headers, TTLs).

Challenges: Different CDNs may handle Vary headers or language cookies differently. Therefore, test each language version on all CDNs. Use a unified cache invalidation mechanism: when you update a translation, you must clear cache tags across all providers simultaneously. In practice, a central cache management tool that sends purge requests to all CDNs in parallel has proven effective. In the event of a CDN failure, automatic failover to a backup CDN should be triggered via DNS (shorten TTL) or client-side JavaScript (if SEO is not critical).

Cost aspects: Multi-CDN does not necessarily double costs because you can use traffic splitting. Negotiate volume discounts with providers. Pay attention to contractual data processing agreements (DPA) with each provider. Document failover processes and test them regularly (e.g., quarterly). A multi-CDN approach is particularly recommended for business-critical multilingual portals aiming for 99.99% availability.

Integration with common CMS and translation management systems

Seamless integration of a CDN with your content management system (CMS) and translation management system (TMS) is key to automated multilingual workflows. In practice, this means: your CMS generates separate URLs or a language slug for each language, the TMS delivers translated content, and the CDN serves it from the edge. We recommend modeling language versions as independent URLs (e.g., /de/, /fr/), as the CDN can then cache per path and the Vary header becomes less complex.

Concrete integration: Many CMS platforms (like WordPress, Drupal, Contentful) offer plugins or modules for multilingual output. These should mark content with hreflang tags and use a clear URL structure. The TMS (e.g., Smartling, Lokalise, memoQ) can push translations directly into the CMS via API. For CDN connection, it is crucial that the CMS or TMS controls cache invalidation – for example, via a webhook that sends a purge request to the CDN upon translation completion. In practice, it has proven effective to clear the cache for exactly that page and possibly overarching navigation areas when publishing a new language version.

Challenges: Dynamic elements such as personalization or user profiles cannot be served purely edge-based. Use edge workers here that read the language from a cookie and make the corresponding CMS call. For static content (blog articles, product pages), we recommend fully pre-caching. Ensure your CMS sets locale correction (e.g., date formats, currencies) server-side, as the CDN does not include formatting logic. Test the integration in a staging environment with all components.

Best practice: Define a unified API endpoint for language content that your frontends and the CDN use. Use cache tags to invalidate related resources together (e.g., all pages of a language version). Document the workflow from translation request to delivery at the edge. Close collaboration between the development team, translators, and CDN administrator is essential. We recommend conducting regular reviews of cache hit rates per language to identify optimization potential.

Testing procedures and quality assurance for distributed content

Quality assurance for multilingual CDN-based websites requires specific testing procedures that cover both technical and linguistic aspects. A central element is testing the geo-routing logic: simulate accesses from different European countries using VPNs or CDN-specific testing tools. Check whether the correct language version is delivered by measuring both the HTTP status code and the response time. For each target region, test at least three different locations to ensure consistency. Note that CDN edge nodes in neighboring countries may have different configurations depending on the provider—record the actual pop locations (Points of Presence) for later error analysis.

Another focus is the correct interpretation of the Vary header. Use tools like curl or specialized browser extensions to capture the sent headers. Ensure that your CDN includes the Vary header with relevant fields (e.g., Accept-Language, Cookie) and does not incorrectly restrict it to content type or encoding. Perform load tests with different Accept-Language values to rule out cache poisoning. Repeat these tests after every cache setup or configuration change. Document all results in a central test matrix, which will serve as a baseline for later monitoring.

For dynamic content that is personalized or user-specific, a multi-stage approach is recommended: first check correct functionality without CDN (directly on the origin server), then with CDN enabled, and finally with geo-routing enabled. Pay attention to the cache hit rate: a low rate may indicate inefficient Vary headers or too short TTLs. Additionally, measure delivery time for each language version—practical experience shows that latency differences of over 200 milliseconds between different regions can indicate suboptimal CDN configuration. Aggregate these metrics over at least one week to account for seasonal fluctuations.

Finally, we recommend integrating an automated test script into your CI/CD pipeline. Simulate requests for all relevant language combinations from various European regions regularly (e.g., once daily). Include the results in a dashboard that also covers the cache hit rate and the number of successfully delivered hreflang tags. Only through this combination of manual samples and automated checks can you ensure that your multilingual CDN strategy works reliably and minimizes SEO risks.

Checklist: Production Deployment and Monitoring

Before going live with your multilingual CDN configuration, go through this checklist to avoid common errors. First, check that the Vary header is set correctly for each language version and that your CDN passes this header to the client—especially with HTTPS. Test the geo-routing rules using at least five different locations in Europe; record latency values and compare them with your SLAs. Also ensure that your DNS configuration is consistent: CNAME records should point to the correct CDN endpoints and not cause unnecessary redirects. Conduct a TTL audit: dynamic content should have shorter TTLs (seconds to minutes), while static JavaScript or CSS files should have longer durations (hours to days).

Set up comprehensive monitoring that goes beyond mere availability. Measure actual latency times per edge pop and per language version—many CDNs offer APIs or third-party integrations for this. Watch for anomalies such as sudden increases in cache miss rate or unexpected response times. Note the thresholds that you define as critical (e.g., latency above 1 second for main pages). Install synthetic monitors that regularly check the delivery of all language versions and alert in case of deviations. Document escalation paths for error cases, including those responsible for language quality and CDN configuration.

Another point is monitoring cache efficiency. Track hit rates per CDN pop; values below 70% for static assets often indicate missing cache key optimization. Regularly check whether your CDN is actually caching content at the edge nodes, or whether pass-through modes are active that forward every request to the origin server. Set up an alerting system that notifies you when the hit rate of a pop falls below a defined threshold. Combine this data with your latency measurements to identify hotspots early.

Don't forget log management: enable access logs or real-time streams from your CDN and forward them to a SIEM or analysis tool. Pay special attention to 404 errors for localized pages—these can indicate missing translations or incorrect geo-routing rules. Schedule regular manual spot checks where a native speaker clicks through at least one language version completely every quarter. Only through a combination of automated monitoring and human review can you ensure a consistent, performant, and legally compliant multilingual website in production operation. Always have all legal aspects (GDPR, cookie notices) reviewed by your legal department—this guide does not replace legal advice.

Common Error Sources and Problem Solutions for Multilingual CDN Implementations

When setting up a multilingual CDN, similar errors repeatedly occur in practice. A central problem is the incorrect configuration of the Vary header. If, for example, you only use the Accept-Language header, but the Vary header does not include all relevant criteria (such as URL path or cookie), the CDN may deliver the wrong language version. Therefore, always check that the Vary header matches the actual cache keys used. Another typical error is the lack of a fallback language. If a user comes from a region for which no dedicated language version exists, a default language (e.g., English) should be delivered – otherwise, you get empty pages or error messages. Geolocation is also error-prone: users surfing via VPN or near borders may receive the wrong language version. Here, it is advisable to provide a manual language switcher on the website and store the user's decision via a cookie. The interplay between hreflang tags and CDN geo-routing can also lead to conflicts. Ensure that the hreflang tags output in the HTML match the actually delivered language version, otherwise you signal inconsistent content to search engines. When troubleshooting, it helps to analyze the HTTP response headers of the delivered pages – especially the cache headers, the Vary header, and any geo headers. Tools like curl with custom headers or browser-based developer tools are helpful here. Document your configuration and perform regular tests with users from different regions. Note that errors in CDN configuration not only impair the user experience but can also have negative effects on search engine rankings. If in doubt, consult an expert for CDN and localization – careful configuration saves a lot of effort later.

Tools and automation for managing multilingual content in the CDN

To efficiently operate a multilingual website with a CDN, you should rely on specialized tools and automation. A central element is a cache management tool that allows targeted invalidation of language versions. Many CDN providers offer APIs that allow you to clear the cache only for the affected paths when updating individual language pages – this avoids unnecessary cache resets for all language versions. For managing translations and their delivery, the use of a Translation Management System (TMS) is recommended, ideally with direct integration into your CMS and CDN. This way, you can automatically deploy language versions from the TMS to the CDN and provide them with the correct headers. For monitoring delivery quality, use a synthetic testing tool that regularly simulates requests from different geo-regions and checks the delivered language version, load time, and correctness of headers. If you operate a multi-CDN setup, a traffic management tool such as anycast DNS with health checks simplifies distribution across different providers. Ensure that your monitoring solution also tests language switching: simulate users who change the language via a cookie or URL parameter, and check whether the next request receives the correct variant. Additionally, you can set up CI/CD pipelines that automatically clear the cache for the affected paths and reset the HTTP headers with every translation update. All these tools require careful setup and regular maintenance. Plan sufficient time for initial configuration and train your employees in using the systems. Well-thought-out automation reduces errors and relieves your team – but it does not replace manual quality control, especially when checking linguistic correctness and compliance with legal requirements.