Next.js SEO, fixed in your repo and checked on your live site

Because in Next.js, nearly every SEO setting is code. Titles, descriptions, canonicals and robots rules come from the metadata object or generateMetadata in your layouts and pages, and sitemaps, robots.txt and Open Graph images come from special files in the app folder.

So an SEO fix on a Next.js site is a code change, reviewed and deployed like any other. A plugin or dashboard can't edit your templates; a pull request can. That is why LogNorm pairs its audits with a coding agent working in your repo, and why it can publish articles as pull requests as well.

Most findings from LogNorm's SEO audit map to one place in the App Router. The table shows where an agent usually looks first.

The GEO audit reads pages without running JavaScript, as many AI crawlers do. If key content only appears after client-side scripts run, it is flagged as invisible to them, which usually points at a component that should render on the server.

The agent works in the repository that builds your site and LogNorm supplies the work and the check. Critical and warning audit rules become fix moves automatically, one move per rule with every affected URL attached.

1. 1
   Claim

   The agent reads this week's plan over MCP and claims a fix move, so the team sees who is on it.

2. 2
   Fix the cause

   It edits the metadata, sitemap.ts, robots.ts, JSON-LD or llms.txt in your repo, then opens a pull request.

3. 3
   Leave a trail

   It comments the files it changed and the PR link on the move, under its own name.

4. 4
   Deploy and validate

   After your PR is merged and deployed, the agent marks the move published and runs validate_fix.

5. 5
   Close or narrow

   LogNorm re-fetches the affected pages and re-runs that rule. When everything passes the move closes; otherwise it shows what is left.

Claude Code, Codex, Cursor and other MCP clients connect the same way, with one sentence and a browser sign-in. See Claude Code and the AI SEO agent for the full loop.

Yes. If your blog is Markdown or MDX in the repository, connect GitHub as the CMS and each approved article arrives as a pull request instead of a post.

• Each publish creates a new branch with the article at your content path as .mdx or .md, with frontmatter from your template (title, description, slug, date, keyword, image and more).
• Images are committed to your images folder in the same pull request, and the SEO title and description go in the PR description for your reviewer.
• LogNorm checks open pull requests every 15 minutes. Merging marks the piece and its move published; publishing again opens an update PR that edits the same file.

It needs a fine-grained personal access token for that one repository, with Contents: write and Pull requests: write. Because GitHub doesn't report the live address, set a public URL pattern so LogNorm can start measuring. Details are in the publishing docs.

Because the page Google fetches is what counts, and Next.js has several layers between your code and that page. Metadata can be overridden by a nested layout, a route can be dynamic, and a deploy can fail or lag.

For dynamically rendered pages, Next.js streams metadata after the page starts rendering. It puts metadata in the <head> up front only for bots it detects by user agent as expecting it there, a list you can change with the htmlLimitedBots setting. Checking the deployed HTML removes the guesswork. LogNorm's validation reports how many pages are fixed, still failing or not checked, and fixed findings drop out of the audit and the move.