Before enabling automated publishing, prove that one test post can move from content source to the correct public URL and be reversed safely. Ranks supports automatic blog setup and publishing for Next.js App Router websites using TypeScript. Teams that do not meet those conditions can keep autopilot off and publish the supplied Markdown themselves.
Confirm the route, TypeScript, and ownership
Start by confirming that the blog uses App Router rather than Pages Router. Next.js documents these as distinct routing systems. Locate the article route in the app directory, record its expected URL pattern, and publish a disposable test slug through the same path a real article will use.
TypeScript is the eligibility gate for the Ranks autopilot path. Before testing automation, also assign a deployment owner, a content reviewer, and a person authorized to reverse a release. These are team controls, not assumptions about an integration's permissions or connection method.
- Confirm the article route is implemented with App Router.
- Confirm the publishing repository uses TypeScript.
- Document the expected canonical URL, including locale or base-path segments.
- Assign review and rollback ownership before the first automated post.
| Repository condition | Recommended path | Evidence to collect |
|---|---|---|
| Next.js App Router and TypeScript | Evaluate the Ranks autopilot path | A test post renders at its expected URL and has named review and rollback owners. |
| Pages Router, another stack, or unresolved setup | Publish manually | Use the Markdown and copyable prompt supplied with each article. |
| App Router and TypeScript, but no reversible test | Pause automation | Establish a disposable test-post and rollback procedure first. |
Identify the App Router article path and its expected public URL.
Check the rendered page, links, metadata, and sitemap behavior.
Enable automation only after review and reversal responsibilities are clear.
Decide how Markdown or MDX becomes a page
Document how a source article becomes a rendered route in this repository. Use an existing successful post as the reference and identify whether the blog accepts Markdown, MDX, or another content source. List the fields required by the route, such as slug, title, description, date, and body content.
MDX needs an explicit policy. If your renderer allows components in article content, test only the components your team is prepared to support. If the existing pipeline expects plain Markdown, keep incoming content plain. The goal is predictable rendering, not changing formats during a publishing rollout.
When autopilot is off, Ranks provides Markdown and a copyable publishing prompt for each article. That gives a non-ready team a manual route while it adapts content to its established repository conventions.
- Find one live article that uses the same template as the planned blog post.
- Record required front matter or equivalent content fields.
- Test headings, lists, links, code text, and tables on a disposable post.
- Keep the source content, preview URL, and production URL in one publishing record.
Test styling and internal-link destinations
A successful build is not enough. Open the deployed test route and compare it with a known-good article. Check heading hierarchy, readable body width, mobile wrapping, list spacing, table overflow, and link styling. This catches rendering problems that are invisible in a source-file review.
Then open every internal link from the rendered test page. A correct internal link reaches the intended deployed destination. A redirect to an unrelated page, a missing-resource response, or a placeholder URL needs correction before approval. Next.js documents not-found.tsx and notFound() for missing-resource handling, so test destination behavior rather than assuming a path exists.
Keep destination correctness separate from the test post's own availability. A post can be public while one of its internal links is wrong. Record the URLs checked and the observation time for the release record.
- Check the rendered route on desktop and a narrow mobile viewport.
- Open every internal link from the deployed page.
- Confirm that each destination matches the promise of its anchor text.
- Replace placeholders and unpublished destinations before approval.
Verify metadata, sitemap output, and invalid-slug behavior
Next.js supports static metadata through a metadata export and dynamic metadata through generateMetadata in Server Components. Inspect the deployed test page and confirm that its title and description describe that article rather than a generic site fallback. If metadata is generated from the slug, test both a valid slug and an invalid one.
Next.js also supports sitemap.(xml|js|ts) conventions, including programmatic sitemap generation in TypeScript. Open the deployed sitemap after the test publication and check for the exact canonical article URL if your sitemap is designed to include posts. Sitemap inclusion, public availability, and confirmed search indexing are separate observations.
Finally, request an intentionally invalid article slug. Next.js documents error.tsx as a route-segment error boundary and not-found.tsx with notFound() for missing resources. The desired result is your intended missing-post experience, not a crash or an unrelated page.
- Inspect the deployed article title and description.
- Open the deployed sitemap and look for the exact canonical URL.
- Request an invalid slug and confirm controlled missing-resource behavior.
- Record the URL and observation time for each result.
The expected article URL renders the intended post.
Each internal link reaches its intended deployed page.
The page exposes article-specific title and description metadata.
The canonical URL appears when the site's sitemap configuration includes posts.
Approve the initial test and document rollback
Use a one-time setup state called ready for automation. Confirm it only after a disposable test post has passed the route, rendering, internal-link, metadata, and rollback checks. A committed file or successful preview alone does not verify the production result. This setup sign-off is separate from approval of individual articles in manual publishing mode.
Write a short rollback runbook before enabling automation. Specify whether the team will revert a content change, remove an item from its content source, or restore a prior deployment. Test the chosen action with a disposable article where possible. Record who can approve the reversal, where the prior version is retained, and how the team will verify the public URL afterward.
Ranks lets customers keep autopilot off to review and publish each article themselves. Stay in manual mode while setup checks remain unresolved. Once the supported setup is ready, autopilot can publish after its automatic checks pass; a human approval for every subsequent article is not part of that automatic mode. A team that needs that approval should keep manual publishing enabled instead.
- Name a reviewer for the initial test before declaring the publishing setup ready for automation.
- Preserve the prior content version and its source location.
- Assign an owner for the documented rollback action.
- After reversal, reopen the public URL and record the observed result.
Use manual Markdown publishing as the fallback
Manual publishing is the right operational mode when the repository is not ready for automation. Take the Markdown and copyable prompt from Ranks, adapt the content to your existing content format, add the required slug and metadata fields, and use the pull request, preview, and deployment process your team already trusts.
A preview is useful but is not final verification. After production deployment, repeat the public-route, internal-link, metadata, sitemap, and invalid-slug checks. Once those checks are repeatable, and the site meets the App Router plus TypeScript requirement, the team has a concrete basis for evaluating automated publishing.
- Convert Markdown only through the repository's established content pipeline.
- Use a fresh test slug before changing a high-value existing article.
- Verify the production page after deployment, not only a local or preview build.
- Remain in manual mode until rollback can be performed and verified confidently.
