Diagnosing Next.js App Router: layouts, metadata, and Server Actions

For an App Router error, separate the server/client boundary, metadata location, and authorization of mutations. This blog currently specifies Next.js 16.2. If your version differs, consult the documentation for that version.

Moving code from layout to page is not enough

Both layouts and pages are Server Components by default. Extract stateful UI into a Client Component rather than merely moving hooks into page.tsx. See Server and Client Components.

This illustrative example keeps only the button client-side:

// Counter.tsx
'use client';
import { useState } from 'react';
export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

// app/page.tsx (Counter.tsx is in the same directory)
import Counter from './Counter';
export default function Page() {
  return <Counter />;
}

Import Counter from the server page and check that clicking changes 0 to 1. If it fails, inspect the first console error and the boundary. Do not move secrets or server data access into the client component.

Compare metadata with the article and URL

metadata and generateMetadata are server-side APIs. Dynamic generation does not itself guarantee better ranking. See the official metadata reference.

Check each title, self-referencing canonical, and language alternative. A Japanese article whose canonical points to the English home page still has a problem even if the language-switch link works. Verify both direct loads and in-app navigation.

Validate input and authorization inside mutations

Server execution alone does not make an action secure. Validate input and the user's permission to change the target record. See Next.js data security.

Reduce the reproduction and keep recovery possible

Choose one failing route and change one factor at a time. Preserve the diff and verify build, direct loading, navigation, and submission.

The earlier suggestion that infrequent OGP changes improve Discover evaluation is withdrawn. Verifying rendering, URLs, and authorization is separate from gaining search or Discover visibility.