Publish Markdown Posts on a SaaS Website

What Manual Markdown Publishing Means

Manual publishing means a team member transfers supplied article content into the site’s normal CMS, repository, or editor, then checks the rendered result before it becomes public. Ranks currently supports automatic setup and publishing for TypeScript Next.js App Router sites. Other stacks can use its manual Markdown integration path.

Your destination platform determines the import method and its field names. Markdown is the content source, while the CMS or repository turns that source into a public page. Articles can be inspected and edited before publishing, and generated articles remain drafts for review when Autopilot is off, according to the Ranks product reference.

• Collect the Markdown article, associated image assets, and approved production domain.
• Choose the established destination: a CMS draft, repository content file, or internal publishing workflow.
• Keep the page unpublished until body content, page settings, and destinations have been checked.

Transfer Markdown Without Breaking Structure

Transfer content in document order. Set the article title as the page’s single visible H1, then recreate lower-level headings at their intended levels. Add paragraphs, ordered lists, unordered lists, quotations, and code blocks as distinct blocks rather than flattening them into plain text.

Convert links deliberately. The CommonMark specification defines a link as link text paired with a destination URI and documents inline and reference-style forms. In the destination editor, retain meaningful anchor text and confirm that each destination is unchanged unless you deliberately replace it with a production URL.

Handle every image as a separate asset. The CommonMark image tutorial documents image syntax and explains that alt text is available when an image cannot display or for visually impaired users. Upload the intended file through the normal site workflow and add useful alternative text describing its content or function.

• Preserve one visible H1 and the supplied H2 and H3 hierarchy.
• Use the editor’s link control for each Markdown link, then check anchor text and destination.
• Keep code blocks separate from body paragraphs and inspect line wrapping in preview.
• Upload body images individually and enter useful alt text.
• Use the site preview to check how its renderer handles transferred content.

Set Metadata, Internal Links, and the CTA

The article body and the page’s publishing configuration are separate tasks. In the fields or configuration files your stack provides, set the slug, SEO title, meta description, canonical URL, and cover or social image where those controls exist. Do not assume these values are embedded in the Markdown.

Do a final destination pass for internal links and the CTA. A link can look correct in a draft but still point to a staging domain, outdated route, or unsuitable relative path. Do not publish until every internal link and CTA uses a production absolute URL or your team’s intentional relative-URL convention.

Ranks describes its articles as containing relevant internal links and a product call to action. Its publishing controls let teams inspect and edit articles before publishing. Use that editorial control to replace placeholders and validate every destination against the production site.

• Record the final slug and planned public URL.
• Enter the approved SEO title and meta description in the applicable site fields.
• Set the approved canonical URL where your stack supports it.
• Check each internal link against the production domain or chosen relative-path convention.
• Open the CTA destination and confirm it reaches the intended product, signup, or contact page.

Worked Example: Transfer a Supplied Markdown Article

This hypothetical example shows a concrete transfer, not a required CMS schema. Suppose a team receives an article with this Markdown: # Best SOC 2 Automation Tools for Startups, followed by ## What Startups Should Compare, a body link written as security questionnaire workflow, and a CTA written as Start a free trial. It also includes a cover image with the intended alt text, “Founder reviewing a SOC 2 readiness checklist.”

The team’s chosen policy is to use absolute production URLs. In its CMS draft, it sets the visible H1 to “Best SOC 2 Automation Tools for Startups”; preserves the H2 “What Startups Should Compare”; and converts the body link through the CMS link control to https://example.com/security-questionnaires. It converts the CTA to https://example.com/signup. The URLs are illustrative example.com values, not destinations to copy for your own site.

For the page-level settings, the hypothetical approved values are: slug soc-2-automation-tools-for-startups, SEO title “Best SOC 2 Automation Tools for Startups”, meta description “Compare SOC 2 automation considerations for startup teams.”, and canonical URL https://example.com/blog/soc-2-automation-tools-for-startups. The team uploads the cover image and enters the supplied alt text in the platform’s image field, if available.

The observable preview result is one H1, the retained H2, a readable cover image, a body link to the production security-questionnaire page, and a CTA to the production signup page. After publishing, opening https://example.com/blog/soc-2-automation-tools-for-startups should show those same visible elements and destinations. Replace every illustrative value with your approved title, URLs, and metadata before publishing.

Preview, Publish, and Verify the Live Page

Preview on desktop and a narrow mobile viewport before publication. Check heading order, paragraph and list spacing, code readability, image placement, and CTA visibility. Correct the relevant source or editor block, then preview again.

Publish through your established CMS or deployment process. After deployment, open the final public URL in a normal browser session and confirm visible text, headings, links, cover, and CTA. Ranks’ publishing guidance distinguishes a generated draft from a live deployment and recommends checking the live URL, text, links, and cover after publication.

Record the final URL and observation time in your publishing record. This confirms current public availability and rendered-page correctness, not search indexing. For post-publication search exposure and visitor checks, use the Search Console and Vercel validation guide.

• Preview the draft on desktop and mobile-sized screens.
• Publish through the established CMS or deployment workflow.
• Open the final public URL after deployment.
• Confirm text, headings, links, cover image, and CTA on the live page.
• Record the URL and the time of the live-page check.