Google Search Console - "amp-story canonical error" causing Web Story to be invalid

[Saran-tech24]

Discussion Type

Question

Discussion Content

Hi everyone,

I'm having an issue with my AMP Web Stories in Google Search Console.

The URL Inspection report shows:

• Web Story is invalid
• Crawled successfully
• Error: amp-story canonical error

Google says the story won't appear in Search results because of this issue.

Details:

• The page is a valid AMP Story.
• Googlebot can crawl the page successfully.
• The AMP validation passes, but Search Console reports an "amp-story canonical error".
• The story URL is generated dynamically in a React/Next.js application.

I'm trying to understand:

1. What exactly causes an amp-story canonical error?
2. Should the canonical URL point to the Web Story itself or to a separate article page?
3. What should the tag look like for AMP Web Stories?
4. Has anyone faced this issue in a Next.js or React-based website?

Current Search Console Message:

Web Story is invalid
amp-story canonical error

Any guidance or examples of a correct canonical setup would be greatly appreciated.

Thanks!

[logusivam]

This error has a precise, well-documented cause, and your specific tech stack (Next.js/React generating the page dynamically) is the most common source of it.

---

1. What exactly causes an amp-story canonical error

An amp-story page is required to be a stand-alone AMP document and must reference itself as canonical. If an AMP Story page instead references a different URL — for example, a separate non-AMP article page — as its canonical, that page triggers the "amp-story canonical error."

This is different from regular AMP pages. With ordinary AMP, the standard pattern is: an AMP page points its rel="canonical" to a separate non-AMP page, and the non-AMP page points back with rel="amphtml". AMP Stories don't follow that pattern. AMP Stories currently have a hard requirement to be self-canonical. There is no separate "full" version — the story page is the canonical page.

This is also confirmed as an intentional, current platform constraint, not a bug: there has been an open request to the AMP project asking that stories not be forced to be self-canonical, specifically so publishers could make a separate page containing an amp-story-player the canonical URL instead — but as of that discussion, self-canonical is still the required behavior.

---

2. Should the canonical URL point to the story itself or a separate article page?

The story itself. This directly answers your question 2 — there is no "correct" alternative here. The <link rel="canonical"> on your AMP Story page must point to the exact same URL the story is served at, not to:

• A separate React/Next.js article page that embeds the story via <amp-story-player>
• A "desktop" or "non-story" version of the same content
• Any URL other than the story page's own address

If you have a separate landing/article page that links to or embeds the story (common in Next.js setups using amp-story-player to show the story inline on a regular page), that landing page is a different, independent page in Google's eyes — it should have its own canonical pointing to itself, completely separate from the story's self-referencing canonical.

---

3. What the <link rel="canonical"> should look like

For the AMP Story page itself:

<!-- On https://yoursite.com/stories/my-story-slug -->
<link rel="canonical" href="https://yoursite.com/stories/my-story-slug">

The href value must be byte-for-byte identical to the actual URL the page is being served at — including:

• Matching protocol (https, not http)
• Matching trailing slash presence/absence
• No query parameters added or stripped between the actual URL and the canonical value
• Matching domain exactly (no www vs non-www mismatch)

This last point is where Next.js dynamic routing very commonly introduces the bug — see below.

---

4. Why this commonly breaks specifically in Next.js / React apps

This is almost always one of these four causes in a dynamically-rendered setup:

A. The canonical is hardcoded or computed from the wrong source

If your <Head> (Next.js next/head, or the App Router generateMetadata) is pulling the canonical URL from a CMS field, a static config, or process.env.SITE_URL rather than the actual resolved route, it can easily end up pointing to a different URL than the one currently being served — especially after a slug change, redirect, or environment mismatch (staging URL leaking into a canonical tag, for example).

Fix — derive it from the actual request/route, not a static value:

// Pages Router example
import Head from 'next/head';
import { useRouter } from 'next/router';

export default function StoryPage({ story }) {
  const router = useRouter();
  const canonicalUrl = `https://yoursite.com${router.asPath.split('?')[0]}`;

  return (
    <>
      <Head>
        <link rel="canonical" href={canonicalUrl} />
      </Head>
      {/* AMP story markup */}
    </>
  );
}

// App Router (generateMetadata) example
export async function generateMetadata({ params }) {
  return {
    alternates: {
      canonical: `https://yoursite.com/stories/${params.slug}`,
    },
  };
}

B. Trailing slash mismatch

If next.config.js has trailingSlash: true but your canonical tag is generated without one (or vice versa), Google sees the canonical href as a different URL than the page it's on — which AMP Story validation flags as not self-canonical even though it "looks" like the same page to a human.

// next.config.js — make sure this setting matches how you build canonical URLs
module.exports = {
  trailingSlash: false, // pick one and be consistent everywhere
};

C. The canonical is missing entirely on first render (hydration timing)

If the canonical <link> tag is injected client-side only (e.g. via a useEffect that runs after mount, rather than being present in the server-rendered HTML), Googlebot may crawl the page before that tag is added to the DOM — since Googlebot needs to see this tag in the version of the page it crawls, a client-side-only injection can result in Googlebot seeing no canonical tag at all, or the wrong one, depending on render timing.

Fix: Ensure the canonical tag is part of the server-rendered or statically-generated HTML (via next/head in getServerSideProps/getStaticProps pages, or generateMetadata in the App Router) — not added after hydration.

D. Dynamic route generating multiple URL variants for the same story

If your dynamic route can be reached via more than one URL pattern (e.g. /stories/[slug] and also /s/[id] redirecting to it, or case-sensitivity differences, or with/without a locale prefix), confirm that every variant either redirects (301) to one canonical URL pattern, or that each variant correctly self-canonicalizes to itself — mixing the two causes exactly this error.

---

How to verify the fix worked

1. View page source (not just dev tools/rendered DOM) on the live story URL — confirm <link rel="canonical"> is present in the raw HTML and points to that exact URL.
2. Run it through the AMP Validator (validator.ampproject.org) to confirm no other AMP errors are introduced.
3. Use the URL Inspection Tool in Search Console (the same tool from your screenshot) → Test Live URL to re-check after deploying the fix. The URL Inspection Tool is the official way to check whether a Web Story is indexed and valid AMP.
4. Request indexing once the live test passes.

---

Important context worth knowing regardless of this fix

Independent of resolving this specific error, it's worth knowing that AMP Web Stories' visibility in Google Search and Discover has declined significantly from where it was at launch. As of March 2024, Google confirmed Web Stories no longer appear with the distinct Web Stories icon in Google Images, even though they may still appear as regular content. Google has also decoupled the AMP infrastructure from core ranking, meaning that launching Web Stories will not inherently boost the organic ranking of your site's standard pages — the format's main remaining value is largely as an on-site engagement/UX asset rather than a major external traffic driver.

This doesn't mean you shouldn't fix the canonical error — a broken/invalid AMP Story won't be served via the AMP cache or eligible for any Story-specific surfaces at all, so the fix is still worth doing if you're keeping the format. But it's useful context if you're deciding how much further engineering effort to invest in the AMP Story format specifically versus a standard responsive page.

Hope this helps — if it answers your question, would you mind marking it as the answer so others searching for the same thing can find it quickly?

[Yigtwxx]

1. What causes the "amp-story canonical error"?

In a standard AMP setup, the <link rel="canonical"> tag inside an AMP page points to its non-AMP "desktop" original version. However, AMP Web Stories do not follow this standard.

AMP Stories must be standalone documents. According to this rule, the canonical URL of an AMP Story page must point directly to itself (self-canonical). If your page points to a different article page that embeds the story instead of pointing to itself, Google flags this as an "amp-story canonical error". This is not a bug; it is a current and intentional requirement of the AMP platform.

2. Where should the Canonical URL point?

It must point exactly to the story itself.
The <link rel="canonical"> tag on your page must not point to:

• A separate article or landing page that embeds the story (e.g., using <amp-story-player>).
• The "desktop" or standard article version of the content.
• Any URL different from the current address of the story page.

3. How should the Canonical tag look?

The tag in your story's code must look exactly like this:

<!-- Assuming the URL is: https://yourdomain.com/stories/my-story -->
<link rel="canonical" href="https://yourdomain.com/stories/my-story">

There is a crucial rule here: The value inside the href and the exact URL the page is currently serving on must be identical (letter-for-letter, byte-for-byte).

• Protocols must match (https instead of http).
• The presence or absence of a trailing slash (/) must match perfectly.
• There should be no added or removed query parameters (like ?id=1).
• The domain structure must be exactly the same (e.g., if there is www in the URL, it must also be in the canonical tag).

4. Why is this common in Next.js / React Apps and how to fix it?

In dynamically generated sites (like Next.js), this mismatch usually happens for 4 main reasons:

A. Incorrect or Hardcoded Canonical URL Calculation

If you pull the canonical URL from environment variables (e.g., process.env.SITE_URL) or a CMS, there might be a discrepancy between the actual route and the generated URL (e.g., a trailing slash in the .env but not in the Next.js route).
Solution: Always dynamically derive the canonical tag from the actual route the page is receiving the request on.

Pages Router Example:

import Head from 'next/head';
import { useRouter } from 'next/router';

export default function StoryPage() {
  const router = useRouter();
  // Strip query parameters to get the exact matching base URL
  const canonicalUrl = `https://yourdomain.com${router.asPath.split('?')[0]}`;

  return (
    <>
      <Head>
        <link rel="canonical" href={canonicalUrl} />
      </Head>
      {/* AMP story code */}
    </>
  );
}

App Router Example (using generateMetadata):

export async function generateMetadata({ params }) {
  return {
    alternates: {
      canonical: `https://yourdomain.com/stories/${params.slug}`,
    },
  };
}

B. Trailing Slash Mismatch

If trailingSlash: true is enabled in your next.config.js, a / is appended to your URLs. If you don't include that slash when generating the canonical URL in your code, Google treats them as two different pages and throws the error, even if they look identical in the browser.
Solution: Ensure the URL you render in the canonical tag strictly matches your trailingSlash setting in next.config.js.

C. Hydration Delay (Client-Side Rendering)

If your canonical tag is injected into the page after it loads via React's useEffect Hook (client-side), Googlebot likely won't see it when it initially crawls the page. Googlebot inspects the raw source HTML before JavaScript is fully executed.
Solution: Make absolutely sure the tag is generated Server-Side Rendered (SSR) and written into the raw HTML (using getStaticProps, getServerSideProps, or the Metadata API in the App Router).

D. Dynamic Routes Generating Multiple URLs

If a story can be accessed with case variations (/Stories/News vs /stories/news) or different routing paths, and each marks itself as canonical, it confuses Google's crawlers.
Solution: Ensure all alternative URLs are redirected (via 301 Redirect) to one single, definitive URL.

---

How to verify your fix?

1. Check the Source Code: Open your story page in the browser, right-click, and select View Page Source (do not use Inspect Element; you must see the raw HTML). Ensure the <link rel="canonical"...> tag is present in the <head> and perfectly matches the URL in your address bar.
2. Use the AMP Validator: Test the page at [validator.ampproject.org](https://validator.ampproject.org/) to see if any other AMP errors exist.
3. Test via Google Search Console: Go to the "URL Inspection" tool where you got the error and click "Test Live URL". If your fix is correct, it will pass, and you can then request indexing.

[hemanth55244]

The amp-story canonical error occurs when the canonical URL in your AMP Web Story is missing, incorrect, redirects, or does not match the actual story URL.

For a standalone AMP Web Story, the canonical tag should point to the story itself:

Do not point the canonical URL to a separate article page unless the story is merely an AMP version of that article. In Next.js/React applications, this error is commonly caused by dynamically generated canonical tags that do not exactly match the final public URL.