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.
| 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. |
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.
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.
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
If the repository is not ready, keep manual publication and use the separate Markdown transfer workflow. That guide covers adapting the source to an existing CMS or repository. This checklist is the setup sign-off for automation; it is not a requirement to manually approve every future automated article.
