What causes "GraphQL request was redirected to ${responsePath}" in gatsbyjs/gatsby?

Update pluginOptions.url to match the canonical endpoint exactly (correct protocol, host, and trailing slash).

GraphQL request was redirected to ${responsePath}

Error message

GraphQL request was redirected to ${responsePath}

What it means

fetch-graphql compares the request path it sent against the path on the response object. If they differ (and the response path is neither undefined nor the full url), the request was redirected — typically because the WordPress site forces a trailing slash, redirects http to https, or rewrites the GraphQL path. Redirects break introspection and schema retrieval, so the plugin refuses to proceed.

Source

Thrown at packages/gatsby-source-wordpress/src/utils/fetch-graphql.ts:780

            }
          }),
      { retries: 5 }
    )

    if (response.data === ``) {
      throw new Error(`GraphQL request returned an empty string.`)
    }

    const { path }: { path: string } = urlUtil.parse(url)

    const responsePath = response.request.path

    if (
      path !== responsePath &&
      responsePath !== undefined &&
      responsePath !== url
    ) {
      throw new Error(`GraphQL request was redirected to ${responsePath}`)
    }

    const contentType: string = response.headers[`content-type`]

    if (!contentType.includes(`application/json;`)) {
      throw new Error(`Unable to connect to WPGraphQL.`)
    }
  } catch (e) {
    if (throwFetchErrors) {
      throw e
    }

    await handleFetchErrors({
      e,
      reporter,
      url,
      timeout,
      variables,

View on GitHub (pinned to 8b06340921)

Solutions

Update pluginOptions.url to match the canonical endpoint exactly (correct protocol, host, and trailing slash).
Disable or adjust any trailing-slash redirect for the GraphQL endpoint.
Hit the URL in a browser and follow the redirect chain to find the canonical form, then use that in pluginOptions.
Ensure WPGraphQL is served from a single stable path (no WPML domain switching).

Example fix

// before
url: `http://wp.example.com/graphql`

// after
url: `https://wp.example.com/graphql/`

Defensive patterns

Strategy: validation

Validate before calling

const canonical = await fetch(url, { method: 'POST', redirect: 'manual' })
if (canonical.status >= 300 && canonical.status < 400) { throw new Error(`GraphQL url redirects to ${canonical.headers.get('location')}; update pluginOptions.url`) }

Type guard

null

Try / catch

try { await fetchGraphQL(opts) } catch (e) { if (/redirected to/.test(e.message)) { reporter.panic(`Fix pluginOptions.url: ${e.message}`) } throw e }

Prevention

Use the canonical endpoint URL (correct protocol, host, trailing slash) in pluginOptions
Disable trailing-slash redirects on the GraphQL path
Resolve all redirects once and pin the final URL

When it happens

Trigger: WordPress configured to redirect /graphql to /graphql/ (or vice versa); http→https redirect not accounted for in pluginOptions.url; WPML or another multilingual plugin redirecting the endpoint; a permalink restructure that moved the GraphQL endpoint.

Common situations: Site migrated from http to https but pluginOptions.url still uses http; permalink/URL structure changed; trailing-slash enforcement plugin active; CDN/proxy rewriting the path.

Related errors

AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13). Data as JSON: /api/errors/668459a80bb1459f. Report an issue: GitHub.