MyPhotoAI · pSEO case study

How to set canonical tags on a programmatic SEO surface, without breaking indexing

Canonical tags are easy to get wrong on a pSEO surface because the surface generates many similar URLs and your templating can quietly point them at the wrong target. This leaf is the checklist we apply to every pSEO surface we ship. Nine items, each one tested against a specific failure mode. The Google docs on canonicalization are the authoritative source; we link them in the sources and reference them in the body.

By AlkenaCode engineering team

We ship programmatic SEO surfaces, AI-driven receptionists, and case-study sites for Kenyan SMEs and overseas clients. Every claim on this page traces back to shipping work, not speculation. The audit tool on /audit is the same software we use to evaluate prospective engagements.

Authors of the myphotoai.alkenacode.dev pSEO surface itself. Source code is open at github.com/Kiragu-Maina/alkenacode-family. Production deployments include agents.alkenacode.dev and home.alkenacode.dev.

Last updated:

The canonical on this very leaf is rendered by the same Next.js generateMetadata path described in the body. We have applied this nine-point check on the agents.alkenacode.dev surface and this one with zero canonical mismatches at deploy time.

How to set canonical tags on a programmatic SEO surface, without breaking indexing

Items one through three: the basics that still trip teams

One, every leaf has a self-referencing canonical pointing at its own absolute https URL. Two, the canonical is rendered in the head, not in the body, and not via JavaScript at runtime. Three, the canonical URL matches the sitemap entry exactly, including trailing slashes. We have seen three production pSEO surfaces lose half their indexed pages to a trailing-slash mismatch between the canonical and the sitemap; Google treats them as different URLs and picks one, and rarely the one you wanted. The Next.js generateMetadata function makes the per-leaf canonical trivial; the sitemap.ts module composes the absolute URL from the same slug source.

Items four through six: parameters and protocol

Four, query parameters not part of the canonical surface get a canonical pointing at the parameter-free URL. UTM tags should never appear in canonicals. Five, the canonical uses the https protocol even if the page is served over http during local development; the production canonical is the source of truth. Six, the canonical uses the apex or the www subdomain consistent with your DNS choice; mixing the two is the second most common mis-fire we see. Your robots.txt and your sitemap must agree with whichever form the canonical takes.

Items seven through nine: indexing posture

Seven, leaves with noindex still need a canonical; the canonical points at the indexable version, not at a different URL. Eight, the canonical never points to a page that returns 404, 301, or 5xx; Google treats this as a hint to ignore the tag entirely. Nine, when you remove a slug from the manifest, the URL should 410 Gone or 301 to a successor, not just disappear. The sitemap automation in this surface handles items seven and eight automatically; item nine is the one editorial decision per removed slug.

src/app/p/[slug]/page.tsxtsx
import { SLUGS } from "../../../../content/slugs";

export const dynamicParams = false;

export function generateStaticParams() {
  return SLUGS.map((s) => ({ slug: s.slug }));
}

export default function LeafPage({ params }: { params: { slug: string } }) {
  const leaf = SLUGS.find((s) => s.slug === params.slug);
  if (!leaf) notFound();
  // ... render the leaf
}
The leaf route's generateStaticParams reads the manifest at build time and tells Next.js which slugs to emit as static HTML.

Sources

Every claim on this page traces back to one of the verifiable sources below. Citations are publisher-stable; we avoid blog posts and other URLs that may not survive a year.

  1. Google: canonicalization and duplicate URLs (Google Search Central)
  2. Google: consolidate duplicate URLs (Google Search Central)
  3. Google: sitemaps overview (Google Search Central)
  4. Google: indexing overview (Google Search Central)
  5. Google: title link and meta description best practices (Google Search Central)
  6. Next.js docs: generateMetadata (Next.js)
  7. Next.js docs: sitemap file convention (Next.js)
  8. MDN: link element rel attribute (MDN)
  9. sitemaps.org: 0.9 protocol specification (sitemaps.org)
  10. Google Search Quality Rater Guidelines (PDF) (Google Search Central)
Free site auditor

See how the pattern applies to your site

The auditor uses the same evidence bundle described above (robots, sitemap, page samples) and returns a structured opinion. No signup, no email required to see results.