Extension Publishing — One-Click Distribution to 10+ Platforms

What Is Extension Publishing?

After you approve a draft in Content Drafts, Citadex offers two ways to publish: server-side direct (your own blog via GitHub or website webhook) and browser-extension syndication (Medium, Substack, dev.to, Hashnode, LinkedIn, etc.). This guide covers the second.

The browser extension is what lets you publish one article to 10+ external platforms in a few minutes instead of an hour. It doesn't actually post automatically — it opens each platform's "new post" page, pre-fills your article body and title, and waits for you to click the platform's own publish button. The hour you save is on copy-paste-formatting-fix per platform; you still keep editorial control on each one.

Two Publish Paths, One Workflow

For most Citadex users the workflow is: GitHub direct for your canonical blog + browser extension for everything else.

Step 1 — Install the Browser Extension

The Citadex extension is available for Chrome, Edge, and Brave. Install once per browser profile.

1. Open Citadex → Settings → Integrations
2. Click Install Browser Extension — it opens the Chrome Web Store page
3. Add to your browser. After install, you'll see a Citadex icon in your toolbar
4. Click the icon, sign in with your Citadex account
5. The extension is now linked to your workspace

The extension stays idle until Citadex queues an article for it to publish. It does not run in the background otherwise.

Step 2 — Log Into Each Platform Once

For each platform you plan to publish to, be logged in to your account in the same browser before triggering publish. The extension uses your existing session cookies — it does not store any platform passwords.

Recommended one-time setup:

• Open new tabs, log into each of: medium.com, substack.com, dev.to, hashnode.com, linkedin.com, hubspot.com, note.com (if Japan market), qiita.com (if Japanese dev market), zenn.dev (same)
• Stay logged in. Modern browsers keep sessions for weeks
• For WordPress / Ghost on your own domain, you also need to be logged in to that domain

If a platform's session has expired when you trigger publish, the extension will open that platform's login page first — log in, refresh the publish flow.

Step 3 — The Publish Flow

After approving a draft, the Publish Confirmation modal appears with all available destinations listed as checkboxes.

For each destination you tick, the extension queues a publish job. Once you confirm:

1. The extension opens a new browser tab for each ticked platform
2. In each tab, it navigates to that platform's "new post" / "compose" page
3. Title, body (Markdown or HTML, converted per platform), and tags are pre-filled
4. You click "Publish" on each platform manually — the extension stops there

Total time for 5 platforms: usually 2–4 minutes.

If you close a tab before clicking Publish on it, that article is not posted. You can retry from Content Drafts: click Re-publish on the article.

Step 4 — Platform-by-Platform Notes

Each platform has quirks worth knowing about.

Medium

• Set "rel=canonical" to your own blog post. This tells Google that the original is on your site, not Medium — protects your SEO authority. The extension does this automatically when your project has a configured primary blog URL.
• "Too promotional" flag. Medium reduces reach for articles that mention the same brand 3+ times. For comparison-style pieces, edit down to 1–2 mentions before publishing, or skip Medium for that article.
• Tags: Pick 3–5 from Medium's auto-suggest. Generic ones (AI, Marketing, SEO) reach broader audiences.

Substack

• Choose "Free" not "Paid subscribers only." AI crawlers can't read paywalled content — defeating the AEO purpose entirely. The publish modal includes a reminder about this.
• Publication choice: If you have multiple Substack publications, the extension defaults to your most-recently-used one. Verify it's the right publication before hitting Publish.

dev.to / Hashnode

• Developer audience. These platforms reduce reach for marketing/SaaS-positioning content that doesn't include code samples or developer-relevant value.
• Best fit: technical AEO articles (e.g., "How to add JSON-LD schema to a React app"), product engineering posts, integration tutorials.
• Avoid: "Best AEO tools" listicles, brand positioning pieces. These will be flagged or get zero reach.

LinkedIn

• Personal article vs Company Page post. The extension supports both. For most articles, personal article from the founder outperforms Company Page (LinkedIn's algorithm favours personal accounts ~5–10x).
• Article length limit: LinkedIn Articles support long-form (up to ~125,000 characters). Pre-fill works for normal Strategy Article output.
• Tags: Optional but recommended — 3 hashtags max for best reach.

WordPress

• For self-hosted WordPress or WordPress.com Business plan: requires API key configured in Integrations.
• For WordPress.com Free / Personal plans: not supported (no API access). Extension publishing only works for paid tiers.

Ghost

• Configure via Ghost Admin API in Settings → Integrations. Once set up, Ghost is actually a candidate for server-side direct (skipping the extension) — often simpler.

HubSpot

• Publishes to HubSpot CMS Blog. Requires the HubSpot integration enabled.
• Articles publish as drafts in HubSpot — you still review in HubSpot's UI before going live there.

note / Qiita / Zenn (Japanese platforms)

• Article must be in Japanese. If your Citadex article is in English, generate the Japanese version first (set output language to Japanese in the Strategy Article modal) before publishing to these platforms.
• note: General consumer/business blogging. Closest analog to Medium for Japanese audiences.
• Qiita: Developer-focused, like dev.to. Same content fit rules.
• Zenn: Developer + tech. Slightly more SaaS-friendly than Qiita.

How to Avoid the "Too Promotional" Trap

The biggest risk in extension publishing is shadow-banning on platforms that flag self-promotional content. The publish modal includes a warning when your article exceeds typical thresholds (3+ mentions of your brand name, soft-sell CTAs, etc.). Three ways to handle:

1. Edit per platform. Create a "Medium edition" with 1–2 brand mentions and a "your-blog edition" with 5–6. The extension lets you customise body content per-destination before publishing.

1. Skip risky platforms for risky articles. A "Best AEO Tools" comparison piece (high brand mention by design) should publish only to your own site + LinkedIn. Skip Medium / dev.to / Hashnode for that article.

1. Publish neutral content to risky platforms. "What is AEO?" or "How to add Schema markup" type articles — minimal brand mentions — fan out freely.

The audit shown in the publish modal isn't a hard block. It's a warning, and you can override when you know the article is intentional.

What Happens If a Publish Fails

If a platform fails mid-publish (rate limit, session expired, network blip):

• That destination shows "Failed — retry" in Content Drafts
• Other destinations still publish normally
• Click Retry on the failed one — the extension reopens that platform and tries again
• After 3 failed retries, the destination is marked Permanently failed — you'll need to investigate (likely a session/auth issue)

You can also manually unsubscribe a destination if it keeps failing: in Settings → Integrations, toggle off the platform. Future articles won't try that destination until you re-enable.

Frequently Asked Questions

Q: Can I publish to a platform without the extension installed?

For server-side destinations (GitHub, custom webhook) — yes. For extension destinations — no, the extension is required because Citadex doesn't store platform credentials.

Q: Is my Citadex content posted automatically while I sleep?

No. The extension only runs when you trigger a publish action and have your browser open. If you close the browser before clicking each platform's "Publish" button, the article isn't posted on those platforms. This is a deliberate safety feature.

Q: Does the extension track me?

The extension reads your platform sessions (cookies for medium.com, substack.com, etc.) only when actively publishing. It doesn't read any other browsing data, doesn't run when idle, and doesn't send anything back to Citadex except job-status updates ("medium publish complete" etc.).

Q: Can I customise the body content per platform before publishing?

Yes. In the Publish Confirmation modal, click Edit per platform next to each destination. Modify the article body for that destination only (e.g., trim brand mentions for Medium, add code samples for dev.to). The destination-specific edits don't affect the master article on your own blog.

Q: How do I get my Substack newsletter to send the article as an email?

The extension publishes to Substack as a regular post. To trigger the email send, go to Substack after publishing, edit the post, and click "Send as email." This is a Substack UX limitation — the extension can't trigger email send from outside.

Q: My article published to Medium but got 0 views — why?

Most likely "promotional content" flag. Medium is the strictest platform on this. Check: how many times does your article mention your brand name? If 3+, that's the cause. Edit down on Medium and re-publish, or accept that Medium isn't the right channel for that specific article.

Q: Can I batch-republish old articles to a new platform I just added?

Yes — go to Content Drafts → filter by "Approved." Multi-select articles, click Bulk publish, pick the new destination. The extension will queue them all (one tab per article, opened sequentially to avoid rate limits).