WPML GraphQL: worth it for serious multilingual headless sites

WPML GraphQL is a useful integration, not a complete multilingual product by itself. It extends the WPGraphQL schema so a headless frontend can request content by language, retrieve translations, and expose multilingual menus. The practical use case is a WordPress backend serving a JavaScript frontend built with Next.js, Nuxt, Astro, Gatsby, or a similar framework.

The strongest part is the shape of the API. Queries can filter posts, custom post types, taxonomies, menus, menu items, and comments with a language argument. A translations field can return alternate versions of a post or taxonomy in the same response, while languages and defaultLanguage provide enough information to build a language switcher without hard-coding every locale. Connected taxonomies generally follow the language selected on the top-level query, which avoids a lot of repetitive frontend logic.

It also fits well into a broader developer workflow. WPGraphQL includes a GraphQL IDE in the WordPress dashboard, and WPML’s documentation shows testing language queries there before wiring them into a frontend. With ACFML and WPGraphQL for Advanced Custom Fields installed, custom fields follow the language of their host post. Menu and menu-item support was added in WPML GraphQL 1.1.0, making the add-on more useful for complete headless sites rather than just content feeds.

The catch is the dependency stack. You need WPGraphQL, WPML, WPML String Translation, and WPML GraphQL; ACF projects may also need ACFML and WPGraphQL for ACF. WPML says the add-on is available through its Multilingual CMS or Agency plans, so this is not a cheap way to add GraphQL to an otherwise ordinary WordPress site. If you only need an API, install WPGraphQL itself. If you need multilingual content but render through a normal WordPress theme, WPML’s regular frontend features are more relevant than this add-on.

Reliability is good enough for planned, developer-led projects, but it is not frictionless. WPML currently lists an unresolved issue involving translated posts queried by slug in secondary languages when Types Order is active; the documented workaround is to disable Types Order’s Auto Sort option. Its documentation also warns that some translated URI query shapes can return inconsistent paths, so routing should be tested in the GraphQL IDE rather than assumed to work. Author and user metadata does not return translated values either, requiring a workaround such as storing translated bios in ACF fields.

Compared with Polylang, WPML GraphQL has the clearer official path for this specific WPGraphQL use case, but WPML is heavier and more expensive as a complete stack. Compared with TranslatePress, it is far better suited to structured, API-driven content than visual translation workflows. Compared with WPGraphQL alone, it is the missing multilingual layer, not an alternative. The verdict is therefore positive for teams already committed to WPML and headless WordPress, but negative for anyone looking for a lightweight, plug-and-play solution.