DEV Community: Level Up Digital Marketing Group

Your Next.js Site Has Four Copies of Every Page. Here Is How to Tell Google Which One Counts

Level Up Digital Marketing Group — Mon, 02 Nov 2026 19:58:20 +0000

You ship one page. Google can crawl it at four or five different URLs, and it treats every one of them as a separate document until you say otherwise. On a Next.js site deployed to Vercel, most of those duplicates are created by defaults you never chose, and they quietly split your rankings across addresses that should have been one.

This is the cleanup pass I do on every service business site before touching content. It takes about an hour and it is almost entirely config.

Where the copies come from

Take a single page, /services/water-heater-repair. Here are the URLs a crawler can end up fetching for it:

https://example.com/services/water-heater-repair
https://www.example.com/services/water-heater-repair
https://example.com/services/water-heater-repair/ (trailing slash)
https://example.com/services/water-heater-repair?utm_source=gbp (any query string)
https://my-site-git-main-team.vercel.app/services/water-heater-repair (preview and branch deployments)

Each one returns 200 with the same HTML. Each one can collect its own inbound links. The Google Business Profile link uses the UTM version, the footer uses the trailing slash version, a partner links to www, and now the page's authority is spread over four addresses. Google will usually pick one as the canonical, but "usually" is not a strategy, and the pick is not always the one you want.

The fix is four small decisions, each enforced in code.

Decision 1: one host, one scheme

Pick apex or www and redirect the other with a permanent redirect. On Vercel the clean way is in the project's Domains settings: add both, mark one as a redirect to the other, and Vercel answers with a 308 at the edge before your app runs. HTTP to HTTPS is handled there too.

If you cannot control the domain layer, do it in middleware so it is still a single redirect hop:

// middleware.ts (proxy.ts on Next.js 16 and later)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  const host = req.headers.get('host') ?? '';
  if (host.startsWith('www.')) {
    const url = new URL(req.url);
    url.hostname = host.replace(/^www\./, '');
    return NextResponse.redirect(url, 308);
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!_next|api|.*\\..*).*)'],
};

One hop matters. A chain of www to apex to trailing slash to final page wastes crawl budget and leaks a little signal at every step.

Decision 2: pick a trailing slash policy and let Next.js enforce it

Next.js has an opinion here and will redirect for you, but only if you set it:

// next.config.js
module.exports = {
  trailingSlash: false,
};

With trailingSlash: false, a request to /services/ gets a 308 to /services. With true, it goes the other way. Either choice is fine. The mistake is leaving it unset and then linking to both forms from inside your own site, which is what happens when a CMS stores slugs one way and a template writes them another. This is also where your internal links start pointing at mixed versions, and the internal link graph Google actually builds from your site gets fragmented before any external link shows up.

Decision 3: declare the canonical on every page, from the data

A canonical tag tells Google which URL is the real one when it finds a duplicate. Query strings are the big reason you need it: you cannot redirect away ?utm_source=gbp without breaking attribution, so you keep the parameter and point the canonical at the clean path.

In the App Router this is two pieces. Set the base once in the root layout:

// app/layout.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  metadataBase: new URL('https://example.com'),
};

Then set the canonical per route from the same slug the page renders from. Do not hardcode it, and do not put a canonical in the root layout, because every page would inherit the homepage as its canonical:

// app/services/[slug]/page.tsx
import type { Metadata } from 'next';

type Props = { params: Promise<{ slug: string }> };

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  return {
    alternates: { canonical: `/services/${slug}` },
  };
}

Next.js resolves the relative path against metadataBase and writes <link rel="canonical" href="https://example.com/services/water-heater-repair">. The query string is never part of it, which is the whole point. If the slug comes from Sanity or another CMS, this is one query away from being correct on every page forever.

A sanity check I run after this ships: open five pages with junk parameters on the end and view source. Every one should show a canonical with no ? in it.

Decision 4: keep preview deployments out of the index

Vercel adds an X-Robots-Tag: noindex header to preview deployments automatically, so the *.vercel.app URLs for branches and pull requests do not get indexed on their own. The gap is anything that looks like production but is not: a staging custom domain, a client review domain, or a branch you aliased to something memorable. Those get crawled like any other site.

Make the robots file follow the environment instead of the code:

// app/robots.ts
import type { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  const isProduction = process.env.VERCEL_ENV === 'production';

  if (!isProduction) {
    return { rules: { userAgent: '*', disallow: '/' } };
  }

  return {
    rules: { userAgent: '*', allow: '/' },
    sitemap: 'https://example.com/sitemap.xml',
  };
}

A disallow in robots.txt keeps crawlers from fetching pages, but a URL that is already linked somewhere can still appear in results without content. For a staging domain that has ever been public, add a noindex header in middleware under the same VERCEL_ENV check so the pages drop out instead of lingering.

How to confirm it worked

Three checks, in order of effort.

First, hit the variants from a terminal and read the status codes. You want a single 308 to the canonical form, then a 200:

for u in \
  "http://example.com/services" \
  "https://www.example.com/services" \
  "https://example.com/services/" \
  "https://example.com/services?utm_source=test"
do
  echo "== $u"
  curl -sIL "$u" | grep -iE '^(HTTP|location)'
done

Second, in Google Search Console, run URL Inspection on a page and compare "User-declared canonical" with "Google-selected canonical". When they match on your five most important pages, Google agrees with your config. When they do not, Google is seeing a signal you are not, usually a flood of internal links to the other version.

Third, search site:example.com and look for the same title twice. Duplicates in that list are the ones still leaking.

None of this makes a page rank. It makes sure the page you built is the only page competing for the spot, which is the first thing we fix in the SEO work we do for service business sites, because content effort spent on a page with three doubles is effort divided by four.

Written by the team at Level Up Digital Marketing Group, a San Diego agency that builds and ranks service business websites on Next.js and Vercel.

Stop Guessing Which Ad Produced the Lead: Capture gclid in Next.js and Send the Conversion Server-Side

Level Up Digital Marketing Group — Tue, 20 Oct 2026 21:18:30 +0000

A marketing team asks you a simple question: which campaign produced the twelve leads that came in last week? You open the database. Every lead has a name, an email, a message, and a timestamp. Nothing about where the person came from. The ad platform says it drove forty clicks. Analytics says eight form submissions. Nobody can connect a single row in your leads table to a single ad.

This is fixable in an afternoon, and the fix lives in your codebase, not in a marketing tool. The plan: persist the click identifiers and UTM parameters the moment a visitor lands, attach them to the lead when the form posts, and send the conversion event from the server so it survives ad blockers and abandoned tabs.

Why client-side tracking alone misses leads

The usual setup fires a conversion from a gtag call on the thank you page. It works until it does not. Content blockers strip the tag. The visitor closes the tab before the redirect finishes. The form posts to an API route and the page never changes. Each of those cases is a real lead the ad platform never hears about, which means the bidding algorithm learns from an incomplete picture.

Server-side events solve the delivery problem. The attribution problem is separate: you still need to know which click the lead belongs to. Google Ads appends a gclid parameter to the landing URL on every click, and Meta, Microsoft and others do the same with their own identifiers. Capture it on first touch, keep it for the length of the buying cycle, and write it to the lead. The same approach covers referrals from AI assistants, which matters now that GA4 separates AI traffic into its own channel: a lead that arrived from a chat answer should say so in your database, not only in a report.

Step one: persist attribution in middleware

Next.js middleware runs on every request before rendering, which makes it the right place to read query parameters and set cookies without touching page components.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export const ATTR_KEYS = [
  'gclid', 'gbraid', 'wbraid', 'fbclid', 'msclkid',
  'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
]

export function middleware(req: NextRequest) {
  const res = NextResponse.next()
  const params = req.nextUrl.searchParams

  for (const key of ATTR_KEYS) {
    const value = params.get(key)
    if (!value) continue
    res.cookies.set(`attr_${key}`, value.slice(0, 200), {
      maxAge: 60 * 60 * 24 * 90,
      sameSite: 'lax',
      secure: process.env.NODE_ENV === 'production',
      path: '/',
    })
  }

  if (params.toString().length > 0 && !req.cookies.get('attr_landing')) {
    res.cookies.set('attr_landing', req.nextUrl.pathname, {
      maxAge: 60 * 60 * 24 * 90,
      sameSite: 'lax',
      path: '/',
    })
  }

  return res
}

export const config = {
  matcher: ['/((?!_next|api|.*\\..*).*)'],
}

Two decisions are baked in here. Ninety days covers most service business buying cycles, where someone clicks an ad in March and books in May. Last touch wins for the click identifiers, because that is how the ad platforms attribute by default and you want your numbers to match theirs. If you need first touch as well, store it under a second cookie prefix and skip the write when it already exists, the same way attr_landing works above.

If your site has to honor a consent banner, gate the cookies.set calls behind the consent cookie. The attribution still works for everyone who accepts, and the code path stays the same.

Step two: attach attribution when the lead posts

The form posts to a route handler. Read the cookies there, write them to the lead row, and you have a permanent record of the source for every lead, independent of whatever the analytics tool decides to keep.

// app/api/lead/route.ts
import { cookies } from 'next/headers'
import { NextResponse } from 'next/server'
import { ATTR_KEYS } from '@/middleware'
import { db } from '@/lib/db'

function gaClientId(raw?: string) {
  // _ga looks like GA1.1.1234567890.1700000000
  const parts = raw?.split('.') ?? []
  return parts.length >= 4 ? `${parts[2]}.${parts[3]}` : undefined
}

export async function POST(req: Request) {
  const body = await req.json()
  const jar = await cookies()

  const attribution = Object.fromEntries(
    ATTR_KEYS.map((k) => [k, jar.get(`attr_${k}`)?.value ?? null]),
  )
  const clientId = gaClientId(jar.get('_ga')?.value) ?? crypto.randomUUID()

  const lead = await db.lead.create({
    data: {
      name: body.name,
      email: body.email,
      message: body.message,
      landingPath: jar.get('attr_landing')?.value ?? null,
      gaClientId: clientId,
      ...attribution,
    },
  })

  await sendServerEvent(clientId, lead.id, attribution)

  return NextResponse.json({ ok: true, id: lead.id })
}

The _ga cookie is the piece most people skip. Its last two segments are the GA4 client ID for that browser. Sending the server event with the same client ID lets GA4 stitch the lead to the session that produced it, so the event inherits the session's source, medium and campaign. Without it, the event still records, but as a brand new user with no origin.

Step three: send the conversion from the server

GA4's Measurement Protocol accepts events over plain HTTPS. Create an API secret under the data stream settings, store it with the measurement ID in environment variables, and post the event.

// lib/ga.ts
export async function sendServerEvent(
  clientId: string,
  leadId: string,
  attribution: Record<string, string | null>,
) {
  const endpoint = new URL('https://www.google-analytics.com/mp/collect')
  endpoint.searchParams.set('measurement_id', process.env.GA_MEASUREMENT_ID!)
  endpoint.searchParams.set('api_secret', process.env.GA_API_SECRET!)

  const res = await fetch(endpoint, {
    method: 'POST',
    body: JSON.stringify({
      client_id: clientId,
      events: [
        {
          name: 'generate_lead',
          params: {
            lead_id: leadId,
            lead_source:
              attribution.utm_source ??
              (attribution.gclid || attribution.gbraid || attribution.wbraid
                ? 'google_ads'
                : 'direct'),
            has_click_id: Boolean(attribution.gclid || attribution.fbclid || attribution.msclkid),
          },
        },
      ],
    }),
  })

  if (!res.ok) console.error('GA4 MP rejected event', res.status)
}

While you are building, swap /mp/collect for /debug/mp/collect. The debug endpoint returns validation messages instead of a silent 204, which saves a lot of guessing about field names.

Then do the two things that make the event useful to the people buying the ads. In GA4, mark generate_lead as a key event. In Google Ads, with the GA4 property linked, import that key event as a conversion. From that point the ad platform optimizes against leads that actually reached your database, not against page loads.

What this gives the business

Every lead row now answers the question the marketing team asked at the start, and it answers it from your own database. You can group leads by campaign in SQL, compare cost per lead across channels with numbers you trust, and hand the sales team the context of how each person found you.

When we manage paid search for a service business, this attribution plumbing is the first thing we check, because a bidding algorithm fed by half the conversions will happily spend the whole budget on the wrong half.

The next step, once the data is clean, is routing: getting the lead to the right person within minutes instead of letting it sit in a table. That is a workflow problem more than a code problem, and lead routing is where most marketing stacks bottleneck. But none of it works until the lead knows where it came from. Start there.

Level Up Digital Marketing Group builds Next.js sites and marketing systems for service businesses in San Diego. More at levelupdigitalmarketinggroup.com.

Pipe Search Console Into Claude: A Small Node Script That Writes Your Weekly SEO Brief

Level Up Digital Marketing Group — Mon, 05 Oct 2026 17:41:38 +0000

Most developers who own a marketing site check Search Console the same way: open it, click around for ten minutes, close it, forget what you saw. The data is good. The habit is bad. The fix is a script that pulls the last few weeks of numbers, compares the most recent window to the one before it, and hands the deltas to a model that writes three paragraphs you will actually read on Monday morning.

Here is the whole thing. It runs on a cron, costs very little, and has nothing to do with dashboards.

What the script does

Query the Search Console API for the last 28 days of clicks and impressions, split by query and by page.
Split that into two 14 day windows and compute the change per query and per page.
Sort the biggest movers in both directions.
Send the movers to Claude with a short, strict prompt.
Put the result wherever you read things: Slack, email, a Notion page, a text file.

The model is not analyzing the raw data. It is turning a sorted list of changes into sentences. That distinction keeps the output grounded and keeps the token bill small.

Why two windows instead of a plain weekly total? A total tells you the site got 412 clicks. It does not tell you that one page gained 90 and another lost 110, which is the only part worth your attention. Comparing like for like periods surfaces movement, and movement is what you can act on.

Setup

You need a Google Cloud service account with the Search Console API enabled, added as a user on the property in Search Console (Settings, then Users and permissions; Full or Restricted both work for reads). Download the JSON key. Set three environment variables:

GOOGLE_APPLICATION_CREDENTIALS=./sc-key.json
SC_SITE_URL=sc-domain:example.com
ANTHROPIC_API_KEY=sk-ant-...

Use the sc-domain: form if your property is a domain property, or the full https://www.example.com/ URL if it is a URL prefix property. Install two packages:

npm install googleapis @anthropic-ai/sdk

Pulling the data

// gsc.js
import { google } from 'googleapis';

const auth = new google.auth.GoogleAuth({
  scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
});
const sc = google.searchconsole({ version: 'v1', auth });

export async function fetchRows(startDate, endDate, dimension) {
  const res = await sc.searchanalytics.query({
    siteUrl: process.env.SC_SITE_URL,
    requestBody: {
      startDate,
      endDate,
      dimensions: [dimension],
      rowLimit: 1000,
    },
  });
  return (res.data.rows || []).map((r) => ({
    key: r.keys[0],
    clicks: r.clicks,
    impressions: r.impressions,
    position: r.position,
  }));
}

Search Console data lags by a couple of days, so do not end the window at today. End it three days back and nobody will chase a phantom drop.

If the first call returns a 403, the service account email has not been added to the property yet, or you added it to the wrong property type. The domain property and the URL prefix property are separate entries in Search Console with separate user lists. Run sc.sites.list() once and the response tells you exactly which properties the account can see.

Computing the movers

// compare.js
export function diff(current, previous, limit = 15) {
  const prev = new Map(previous.map((r) => [r.key, r]));
  const rows = current.map((r) => {
    const p = prev.get(r.key) || { clicks: 0, impressions: 0, position: null };
    return {
      key: r.key,
      clicks: r.clicks,
      clicksDelta: r.clicks - p.clicks,
      impressions: r.impressions,
      impressionsDelta: r.impressions - p.impressions,
      position: r.position.toFixed(1),
      prevPosition: p.position ? p.position.toFixed(1) : null,
    };
  });
  const up = [...rows].sort((a, b) => b.clicksDelta - a.clicksDelta).slice(0, limit);
  const down = [...rows].sort((a, b) => a.clicksDelta - b.clicksDelta).slice(0, limit);
  return { up, down };
}

Pages that had traffic last period and none this period will not appear in current. If that matters to you, run the diff in both directions and flag keys that only exist in previous. For most small sites the top and bottom fifteen tell the story.

Writing the brief

// brief.js
import Anthropic from '@anthropic-ai/sdk';
import { fetchRows } from './gsc.js';
import { diff } from './compare.js';

const client = new Anthropic();

function iso(daysAgo) {
  const d = new Date();
  d.setDate(d.getDate() - daysAgo);
  return d.toISOString().slice(0, 10);
}

const [curQ, prevQ, curP, prevP] = await Promise.all([
  fetchRows(iso(16), iso(3), 'query'),
  fetchRows(iso(30), iso(17), 'query'),
  fetchRows(iso(16), iso(3), 'page'),
  fetchRows(iso(30), iso(17), 'page'),
]);

const data = { queries: diff(curQ, prevQ), pages: diff(curP, prevP) };

const prompt = `You are writing a weekly SEO brief for the owner of a small business website.
Use only the data below. Do not invent numbers. Do not speculate about causes you cannot see in the data.
Write three short paragraphs: what went up, what went down, and one thing worth checking this week.
Plain English, no bullet points, no headings.

${JSON.stringify(data, null, 2)}`;

const msg = await client.messages.create({
  model: process.env.CLAUDE_MODEL,
  max_tokens: 800,
  messages: [{ role: 'user', content: prompt }],
});

console.log(msg.content[0].text);

Set CLAUDE_MODEL to the current Sonnet model id from the Anthropic docs. Sonnet is more than enough for this. The input is a few thousand tokens of JSON and the output is three paragraphs.

Scheduling it

A GitHub Actions workflow on a Monday cron is the cheapest option if the repo already lives on GitHub. Store the secrets in the repository settings, write the service account JSON to disk in a step, and send the output wherever you want it.

# .github/workflows/seo-brief.yml
name: Weekly SEO brief
on:
  schedule:
    - cron: '0 14 * * 1'
  workflow_dispatch:
jobs:
  brief:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: echo "$SC_KEY_JSON" > sc-key.json
        env: { SC_KEY_JSON: ${{ secrets.SC_KEY_JSON }} }
      - run: node brief.js > brief.md
        env:
          GOOGLE_APPLICATION_CREDENTIALS: ./sc-key.json
          SC_SITE_URL: ${{ secrets.SC_SITE_URL }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          CLAUDE_MODEL: ${{ vars.CLAUDE_MODEL }}
      - uses: actions/upload-artifact@v4
        with: { name: seo-brief, path: brief.md }

Swap the artifact step for a Slack webhook or an email action once you trust the output. Keep workflow_dispatch in there so you can trigger a run by hand while you are tuning the prompt.

The prompt rules matter more than the model

Three constraints in that prompt do the real work. "Use only the data below" stops it from reaching for general SEO advice. "Do not speculate about causes" stops it from blaming an algorithm update it has no evidence for. "One thing worth checking" forces a single action instead of a to-do list nobody reads. Loosen those and the brief turns into content, and content is the thing you were trying to avoid reading.

Where this goes next

Once the brief lands every Monday, the same pattern extends. Pull GA4 landing page data next to the Search Console rows. Flag pages whose impressions rose while clicks did not, which usually points at the title tag. Diff against the same window last year for seasonal businesses. Each one is another fetch function and another field in the JSON. The model call does not change.

This is the smallest version of what we build when a business wants an in-house AI marketing system on Claude: plain code gathers the facts, the model writes the sentences, and a human reads three paragraphs instead of a dashboard.

Carlynn Espinoza runs Level Up Digital Marketing Group, a San Diego agency building SEO, paid media, and AI systems for service businesses.

Your React App Is Invisible to AI Crawlers. Here Is How to Check in Five Minutes

Level Up Digital Marketing Group — Mon, 28 Sep 2026 22:46:55 +0000

Most of the time when a client tells me "we are not showing up in ChatGPT," the site is a React app that renders everything on the client. The HTML that comes over the wire is a <div id="root"></div> and a script tag. A human with a browser sees a full page. A crawler that does not execute JavaScript sees nothing.

Google runs a rendering queue and will eventually execute your JavaScript. Most AI crawlers do not, or do it inconsistently. If you want to be cited by an AI assistant, the safest assumption is that the bot reads exactly what curl reads. Here is how to check, and what to change.

Step 1: Look at what the bot actually receives

Skip DevTools. DevTools shows you the DOM after hydration, which is not what a crawler gets. Use curl and pretend to be a bot.

curl -s -A "GPTBot" https://example.com/services/plumbing | head -c 3000

Now do the same with a few other user agents that matter right now:

for ua in "GPTBot" "ClaudeBot" "PerplexityBot" "Google-Extended" "Googlebot"; do
  echo "== $ua"
  curl -s -o /dev/null -w "%{http_code} %{size_download} bytes\n" -A "$ua" https://example.com/services/plumbing
done

Two things to read from the output. First, the status code: a 403 for one bot and a 200 for another means a WAF or bot rule is blocking you and you probably did not choose that. Second, the byte count: if the page is 1.8 KB for a bot and 90 KB in the browser, your content is not in the HTML.

Then grep the raw response for something that only exists in your real content, like a phone number or a service name:

curl -s -A "GPTBot" https://example.com/services/plumbing | grep -c "water heater"

Zero means the text is being injected by JavaScript after load. That is the whole problem in one number.

Step 2: Check robots.txt for accidental blocks

A lot of teams copied a robots.txt from a template in 2023 that blocked AI crawlers wholesale, and nobody revisited it. Pull it and look:

curl -s https://example.com/robots.txt

If you see User-agent: GPTBot followed by Disallow: /, you have opted out of being cited. That is a legitimate choice for some businesses. It is a bad choice for a local service company that wants referrals from AI assistants. Decide it on purpose, do not inherit it.

Also check the CDN layer. Cloudflare, Vercel, and others have toggles for AI bot blocking that override anything in your file. The curl status codes in step 1 will reveal that even when robots.txt looks clean.

Step 3: Render the important pages on the server

This is the fix, and in most modern frameworks it is a configuration change, not a rewrite.

In Next.js with the App Router, a page is a server component by default. If your service pages are client components because someone added "use client" at the top for a single interactive widget, move the widget into its own client component and keep the page itself on the server. The HTML will contain the full text on the first response.

// app/services/plumbing/page.tsx  (server component, no "use client")
import QuoteForm from "@/components/QuoteForm"; // this one is "use client"

export default async function PlumbingPage() {
  const data = await getServiceContent("plumbing");
  return (
    <main>
      <h1>{data.title}</h1>
      <p>{data.intro}</p>
      <QuoteForm />
    </main>
  );
}

If you are on Vite plus React with no server, you have three realistic options: prerender the static routes at build time (vite-plugin-ssr, Astro, or a simple prerender script with Playwright), move the marketing pages to a framework that renders on the server and leave the app where it is, or accept that those pages are invisible to non-rendering crawlers. The third one is fine for an authenticated dashboard. It is not fine for the pages you want customers to find.

When we take on a client site, the marketing pages are always server rendered from the start. We build them as static or server-rendered Next.js sites on Vercel, and it costs nothing extra at that scale. The dashboard behind login can be as client-heavy as it wants.

Step 4: Make sure the content is real HTML, not a JSON blob

Some sites technically ship the content in the initial response, but only inside a __NEXT_DATA__ or similar JSON script tag, with the visible markup still rendered client side. Crawlers vary in whether they read that. Do not depend on it. The test is simple: view the raw response and confirm the <h1>, the paragraphs, and the internal links exist as markup.

While you are there, confirm the links are real anchors with href attributes, not onClick handlers on divs. A crawler cannot follow a click handler.

Step 5: Recheck after every deploy

Put the curl checks in CI. A small script that fetches five key URLs as GPTBot, asserts a 200, and asserts that a known phrase exists in the raw body takes ten minutes to write and catches the regression where a developer wraps a layout in "use client" and silently blanks the site for every crawler.

#!/usr/bin/env bash
set -e
for url in "$@"; do
  body=$(curl -s -A "GPTBot" "$url")
  echo "$body" | grep -q "<h1" || { echo "FAIL no h1 in $url"; exit 1; }
  echo "$body" | grep -q "levelupdigitalmarketinggroup\|Call\|Contact" || { echo "FAIL no contact text in $url"; exit 1; }
  echo "ok $url"
done

The short version

Crawlers read source, not screens. Curl your pages as a bot, check the status and the byte count, grep for real content, fix the robots and CDN rules you forgot about, and render the pages that matter on the server. Everything else in AI search optimization sits on top of that, and none of it works if the bot receives an empty div.

Carlynn Espinoza runs Level Up Digital Marketing Group, a San Diego agency that builds and markets websites for local service businesses.

JSON-LD Structured Data: The Developer's Lever for SEO and AI Citations

Level Up Digital Marketing Group — Mon, 21 Sep 2026 21:33:31 +0000

Most SEO advice lands on marketers: write better copy, earn links, fix titles. But there's one high-leverage lever that lives entirely in the codebase, and developers own it outright: structured data.

Structured data (usually JSON-LD) is a small block of machine-readable JSON that tells search engines and AI answer engines exactly what an entity is, instead of making them infer it from prose. It's low effort, it's shippable in an afternoon, and it's increasingly how you get pulled into rich results and cited by AI. Here's the practical version.

What it actually is

JSON-LD is a <script type="application/ld+json"> block you drop in the <head> (or anywhere in the body). It follows the schema.org vocabulary. Nothing renders; it's purely a description for machines.

The minimum viable win for most businesses is an Organization (or LocalBusiness) block:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Plumbing",
  "url": "https://acmeplumbing.com",
  "logo": "https://acmeplumbing.com/logo.png",
  "telephone": "+1-555-123-4567",
  "sameAs": [
    "https://www.linkedin.com/company/acme-plumbing",
    "https://www.g2.com/products/acme-plumbing"
  ]
}
</script>

That sameAs array matters more than it looks: it's how you connect your site to your other verified profiles, which helps engines resolve you as one trusted entity.

Why it matters more now

Two reasons. First, the classic one: rich results. Marked-up reviews, FAQs, breadcrumbs, and products can render enhanced listings that earn more clicks.

Second, the newer one: AI answer engines (ChatGPT, Google's AI Overviews, Perplexity) lean on clearly structured, trustworthy sources when they decide who to cite. Prose forces them to guess; JSON-LD hands them the facts in a format they don't have to interpret. If you want to be quotable by a model, being parseable is step one.

The three blocks worth shipping first

1. Article - on every blog/content page:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Winterize Your Pipes",
  "author": { "@type": "Organization", "name": "Acme Plumbing" },
  "datePublished": "2026-09-21",
  "image": "https://acmeplumbing.com/winterize.jpg"
}

2. BreadcrumbList - gives engines your site hierarchy and can render breadcrumb rich results:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://acmeplumbing.com" },
    { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://acmeplumbing.com/guides" }
  ]
}

3. FAQPage - arguably the highest-ROI for AI citations, because it maps your content to explicit question/answer pairs:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "How much does emergency plumbing cost?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Emergency call-outs typically run $150-$450 depending on the job and time of day."
    }
  }]
}

The gotchas that get people penalized

Mark up what's visible. The structured data must match the content a user actually sees on the page. FAQPage markup for questions that aren't on the page is a spam signal, not a shortcut.
Validate before you ship. Run every template through Google's Rich Results Test and the schema.org validator. A single malformed block can invalidate the whole thing.
One entity, consistent everywhere. Your name, URL, and phone in JSON-LD should match your site, your profiles, and your directory listings exactly. Conflicting data erodes the trust you're trying to build.
Generate it, don't hand-maintain it. In a component-based stack, render the JSON-LD from the same data source as the visible content so they never drift.

Why this is worth an afternoon

Structured data is one of the rare SEO tasks that is fully in a developer's control, ships once, and compounds: better rich-result eligibility and better odds of being cited by AI, from the same block of code. It won't rank a bad site, but on a decent site it's free leverage most competitors skip.

If you want the strategy layer that decides which pages and entities to prioritize on top of the technical implementation, that's what modern AI-native SEO is built to handle. But the JSON-LD itself? Ship it this week. Start with Organization and FAQPage.

Written by the team at Level Up Digital Marketing Group, an AI-native marketing agency helping established service businesses grow through SEO, ads, websites, and smarter use of AI. More at levelupdigitalmarketinggroup.com.