Dacast: untangling a multilingual WordPress site behind a CDN
My Role: Technical SEO consultant. Timeline: I worked on this project in 2026 for roughly 6 months, reporting directly to the Dacast CEO. What happens when you combine a popular content management system, a sophisticated translation plugin, and an aggressive caching layer, and you need to diagnose technical SEO issues quickly? Well, it becomes an engineering challenge. I recently spent roughly 6 months working with Dacast to untangle their complex multilingual setup, relying on strict verification rather than assumptions.
What Was the State of the Dacast Platform?
To explain the state of Dacast, we need to start from the top. Dacast is a live video streaming and OTT platform. Their marketing and knowledge base site runs on WordPress. They use WPML (WordPress Multilingual Plugin), which lets viewers see the site in 5 languages: English (EN), Spanish (ES), French (FR), Italian (IT), and Portuguese (PT). For the rest of the stack, they rely on Yoast SEO Premium for the SEO layer, Elementor and the Flatsome theme for the front end, and CloudFront sits in front of it all as the CDN (Content Delivery Network). When I came on board, the site was still shaking off the impact of recent Google algorithmic updates. On top of that, it carried the kind of heavy technical debt that a large multilingual WordPress installation naturally accumulates over the years. We were looking at thousands of flagged hreflang errors, tangled redirect chains, sitemap entries pointing to redirects, and and mobile Core Web Vitals that had drifted. My job was straightforward. Systematically work through that massive list, verify each fix against reality, and give an honest, weekly report on the platform’s actual state.
Why Was This Setup So Hard to Debug?
Well, the real challenge here was not any single fix. It was the fact that this entire stack is built to mislead you if you aren’t careful and experienced enough. Let me explain. CloudFront can cache pages and sitemaps for up to ten days, but WordPress also has its own object cache, and, on top of all that, WPML adds yet another layer. Because of this setup, the most obvious way to check if a fix worked (loading the URL and reading what comes back) is unreliable in three distinct ways: First, a CloudFront “Hit” simply isn’t the real truth. It’s nothing more than a saved copy that could be days behind the live site. To see what the server is genuinely outputting, you have to trigger a cache “Miss” or request a fresh check right after a CDN invalidation. Second, Google doesn’t see the logged-in admin view. WPML actually injects draft translations into the hreflang tags when you view the site as an admin, but it hides them from regular visitors and Googlebot. Read the page while logged in and you get the wrong answer. And third, toggling a post from draft to published doesn’t update the routing instantly because the object and WPML caches hang onto the old data. If you jump the gun and clear the CDN before flushing those two underlying caches, you will accidentally force the CDN to re-cache the stale routing across every edge server.
I quickly learned that “done” meant absolutely nothing until I verified it myself as an outside user, completely logged out, and I read a fresh response straight from the origin server. That strict verification process is the foundation for everything you will read below.
How Did I Recover Eight Deindexed Flagship Articles?
The clearest example of why strict verification matters happened partway through the process. A batch operation designed to clean up old translations had an unintended side effect. The tooling resolved URLs to post IDs using a function that was not language-aware. As a result, a set of shared multilingual slugs resolved to the English originals instead of the targeted translations. I’m talking about eight of the website’s strongest English articles, and they were unpublished by mistake and quietly dropped out of Google’s index. Now, from the outside, the symptom looked like your standard redirect problem because the articles were 301-ing in loops. Even before I investigated, a cached 200 response on one edge server and a redirect loop on another had already led to two wrong diagnoses. I decided to approach the issue by looking for the origin truth, and I found the real cause. It was the shared-slug collision combined with a cache-order mistake that had baked the loop into the system. I then republished all eight articles, flushed the object and WPML caches in the correct order, and only then invalidated the CDN. Before calling the issue “fixed”, I verified each of the eight URLs from a fresh, logged-out request. And, to stop this from happening again, I ensured the next batch operation was targeted by post ID rather than by slug.
That was, in my opinion, the highest-value task I completed during the engagement, and it only surfaced because I refused to trust the initial read.
How Did I Clear the Multilingual Hreflang and Sitemap Errors?
The largest number on the initial audit was related to hreflang. There were around 1,382 URLs that were flagged for incorrect or broken hreflang issues. Almost all of these were old foreign-language posts that were now 301 redirects to English, but the system was still emitting them as valid language alternates. Now, instead of patching pages one by one, I decided to build the fix at the output layer. I implemented a WPML-aware change that stopped the site from emitting hreflang alternates for translations that no longer resolved, while keeping all the valid ones completely intact. I first had to prove that this approach works, so I tried it on a small test batch. I verified it against the origin, confirmed its efficacy, and then rolled it out. As a result, the error count fell steadily as the crawler caught up. Then, a later independent audit in Search Console confirmed the remainder was purely cosmetic, leaving only one benign canonical case and no real multilingual problems. The sitemap work followed the exact same shape. The XML sitemap was listing URLs that triggered a 301 redirect rather than resolving properly, which shows up in the Search Console as a “page with redirect” error. My fix was to go through every single flagged URL live to separate the ones that were genuinely redirecting from the ones that had simply been crawled at a bad moment. Then, I excluded the redirecting posts and pages using a Yoast filter so the sitemap listed only canonical, 200-status URLs. Resolving the right post IDs for that Yoast filter meant querying the database in a WPML-aware way. That strict process caught two IDs that were actually the English versions of the pages, rather than the Spanish and French ones I needed. If I had been wrong there, the fix would have looked complete from the outside while quietly doing absolutely nothing underneath. Also, naturally, everything went to a staging environment and was strictly verified before ever reaching the production stage.
How Did I Diagnose Core Web Vitals Honestly?
Mobile Core Web Vitals had drifted into the “needs improvement” category, while the desktop metrics were completely clean. I pulled the field data from Search Console and the lab data from PageSpeed Insights and separated the issue into two distinct problems. First, LCP was a server-speed issue. The origin renders an uncached WordPress page in over a second. While CloudFront hides that delay when it’s warm, any cache-cold request pays the full render penalty. Those real, cache-cold visits are exactly what Google measures, and therefore, the fix had to be origin-level, not just a per-page adjustment. Second, CLS was a template issue. On the knowledge base pages, images were loading without set dimensions, and a consent banner shifted the layout as it loaded. This showed up only in field data and not in the lab, which proves that you must debug this against real conditions. I wrote up both problems with their root causes, the specific fixes required, and how to verify them, and I handed that documentation to the development team. When the mobile numbers recovered on their own later, I shared the honest reason with the CEO. The temporary performance hit caused by earlier cache clears had simply dropped off Google’s 28-day rolling average. No one had shipped a fix for this, and naturally, I didn’t claim it as one. I actually made it clear that the durable fix involving the origin and template work was still the best way to go.
What Were My Engineering Habits?
I’ll share a few strict habits that defined this engagement more than any single fix. I verified from the origin truth: I always verified results from the outside, logged out, and after an invalidation. A cached response does not count as evidence. I deliberately under-claimed: If something was 90 percent done, I reported 90 percent, with the exact remainder. I didn’t carry forward status updates. I kept a stage-first focus: I ensured that all reversible, output-layer changes were proven on staging before going into production. I owned my mistakes: When a number in a report was wrong, I corrected it. Also, I never blamed the tooling. This last point is what mattered most. Technical SEO (when we’re talking about a stack like this) gives you a lot of chances to be wrong, and the value I brought was as much about reporting accurately as it was about the fixes themselves.
What Were the Final Results?
These were my accomplishments over the roughly 6-month engagement with Dacast. I recovered eight de-indexed flagship articles and stopped that error class from happening again. I reduced hreflang errors from around 1,382 to effectively clean, which was confirmed by an independent Search Console audit. I traced roughly 200 flagged redirect chains to about 21 real causes and resolved them into clean single hops. I diagnosed mobile LCP and CLS to their actual causes and delivered an actionable remediation plan, while the desktop stayed completely clean throughout. I cleaned up the XML sitemap so that it lists only canonical 200-status URLs. I kept the canonical coverage, structured data, and the rest of the acceptance criteria passing, verifying them live before each weekly report. The engagement closed with the CEO happy with the work and a recommendation in hand.
What Did the Client Say?
Nemanja handled the technical SEO for Dacast, a large multilingual WordPress site with a complex WPML and CloudFront setup. He works in a methodical way and supports his recommendations with real data. He fixed our canonical coverage so there are no flagged issues, and he added schema across our page templates with no validation errors. His best work was finding the root cause: he traced our hreflang, sitemap, and redirect problems back to one source, the way the CMS was creating old, duplicate multilingual references, and then he rebuilt the setup at the source instead of fixing each page one by one. He explains things clearly at a CEO level and is honest about trade-offs. Reliable and very strong on technical SEO.
Pablo Hesse, CEO, Dacast