DEV Community: Muhammed Rashid Kannampurath sadakhathulla

Building a Semi-Automated Content Repurposing Pipeline with n8n

Muhammed Rashid Kannampurath sadakhathulla — Wed, 15 Jul 2026 14:30:34 +0000

Publishing the same core content across multiple platforms (blog, newsletter, social) manually is repetitive enough that it's a reasonable automation target. Fully automating the posting itself — especially to third-party platforms — is a different story, and one worth being honest about upfront: most platforms actively detect and penalize bulk-automated posting, and it can get accounts flagged or banned. This workflow automates the repetitive preparation work and leaves publishing as a deliberate, human-reviewed final step.

The workflow shape

[Trigger: New article published]
        ↓
[HTTP Request: Fetch article content]
        ↓
[Function Node: Extract title, summary, key points]
        ↓
[HTTP Request: Claude/GPT API — generate platform-specific variants]
        ↓
[Split into branches per platform]
        ↓
[Format for LinkedIn] [Format for Twitter/X] [Format for Newsletter]
        ↓
[Google Sheets / Notion: Write drafts to review queue]
        ↓
(Human reviews and manually publishes each)

The key design decision: the last automated step writes to a review queue, not to a publish endpoint. That single change is what keeps this a genuine productivity tool instead of a spam-generation pipeline.

Trigger node

If your blog is a static site rebuilt on push (GitHub Actions, Netlify, etc.), a simple Webhook trigger fired from your deploy pipeline works cleanly:

{
  "path": "new-article-published",
  "httpMethod": "POST",
  "responseMode": "onReceived"
}

Your deploy script POSTs the new article's URL and slug to this webhook once the build succeeds.

Fetching and extracting content

// Function node — strip HTML, extract key fields
const html = $input.item.json.html;
const title = html.match(/<h1>(.*?)<\/h1>/)?.[1] || '';
const firstParagraph = html.match(/<p>(.*?)<\/p>/)?.[1] || '';

return {
  json: {
    title: title,
    summary: firstParagraph,
    url: $input.item.json.url
  }
};

For anything beyond trivial HTML structures, swap this for a proper HTML parser node rather than regex — regex against arbitrary HTML breaks the moment your template changes, and n8n has community nodes for this specifically.

Generating platform variants

This is where an LLM API call earns its place — condensing an 800-word article into a LinkedIn post, a shorter Twitter/X thread opener, and a newsletter blurb are three genuinely different rewriting tasks, not just truncation:

// HTTP Request node body, calling an LLM API
{
  "model": "claude-sonnet-4-6",
  "max_tokens": 500,
  "messages": [{
    "role": "user",
    "content": `Rewrite this article summary as a LinkedIn post (150-200 words, professional tone, ending with a question): ${summary}`
  }]
}

Run this three times with different prompts for the three target formats, or use a single call asking for all three in structured JSON output.

Writing to a review queue instead of publishing

// Google Sheets node — append row
{
  "sheet": "Content Queue",
  "values": {
    "date": "{{$now}}",
    "article_url": "{{$json.url}}",
    "linkedin_draft": "{{$json.linkedin_variant}}",
    "twitter_draft": "{{$json.twitter_variant}}",
    "status": "pending_review"
  }
}

This is the actual output of the automation — a spreadsheet or Notion database with drafts ready for a two-minute human review and manual publish, rather than a bot posting unsupervised.

Why the human step stays manual on purpose

Beyond the platform-detection risk, a human pass catches things automation reliably misses: a rewritten summary that's subtly inaccurate, a tone mismatch for a specific platform's culture, or a link that should point somewhere slightly different for that specific audience. The time saved by this pipeline isn't "zero human involvement" — it's "no longer manually re-reading and re-writing the same content five different ways," which is most of the actual repetitive labor anyway.

I use variations of this pipeline for client content workflows — more at capareach.com.

Migrating a Site from WordPress/Elementor to Static HTML — What Actually Breaks

Muhammed Rashid Kannampurath sadakhathulla — Wed, 15 Jul 2026 14:29:18 +0000

I recently rebuilt a WordPress/Elementor site as static HTML/CSS/JS from scratch. The performance and control gains are real, but a straight "rebuild it and swap the DNS" approach quietly destroys SEO value that took years to build. Here's the checklist of what actually breaks, and the fixes, from doing it firsthand.

1. Every URL that changes needs a 301, not a hope

WordPress generates URLs based on permalink settings, categories, and Elementor's own routing quirks. A static rebuild almost never produces byte-identical URLs. Every URL that changes needs an explicit redirect, or the accumulated backlink authority and search rankings pointing at the old URL simply die.

# .htaccess — old WordPress URL to new static path
Redirect 301 /services/seo-audit/ /seo-audit.html
Redirect 301 /blog/2024/01/technical-seo /blog/technical-seo.html

Pull the full list of indexed URLs from Google Search Console before migration — not from memory, not from the sitemap, from the actual "Pages" report — and map every single one. Anything missed here is invisible SEO loss that won't show up until traffic quietly drops weeks later.

2. Schema markup doesn't come along for free

If your WordPress SEO plugin (Yoast, RankMath) was auto-generating JSON-LD schema, that markup vanishes the moment you're not on WordPress anymore. It needs to be rebuilt manually into the static HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Your Business Name",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Thrissur",
    "addressRegion": "Kerala",
    "addressCountry": "IN"
  },
  "telephone": "+91-XXXXXXXXXX"
}
</script>

Validate every page with Google's Rich Results Test after migration — don't assume the markup you wrote is actually well-formed until it's checked.

3. Meta descriptions and title tags need a real audit, not a template

Elementor/Yoast setups often have per-page meta descriptions set individually. A static rebuild frequently ends up with a single template applied everywhere unless someone specifically pulls the old meta content page-by-page. Export the old meta data from the WordPress database or via Yoast's export tool before decommissioning, so nothing gets lost to a generic fallback.

4. Forms need a new backend, and that backend needs testing under load

WordPress form plugins (Contact Form 7, WPForms) handle spam filtering, submission storage, and email delivery out of the box. A static site needs a third-party form handler (Web3Forms, Formspree, etc.) wired in manually — and critically, tested for what happens on failure, not just success:

fetch('https://api.web3forms.com/submit', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(formData)
})
.then(res => res.json())
.then(data => {
  if (!data.success) {
    // this branch gets skipped in testing more often than it should
    showErrorState();
  }
})
.catch(() => showErrorState());

5. Internal linking structure needs to be rebuilt deliberately

WordPress's category/tag archive pages generate a lot of internal linking automatically, without anyone thinking about it. A static site has none of that unless you build it — meaning internal link equity that used to flow through auto-generated archive pages needs an intentional replacement: related-post sections, manually curated category pages, a proper sitemap.

6. The GSC/analytics transition needs overlap, not a hard cutover

Keep the old GSC property and the new one both verified and monitoring in parallel for at least a few weeks post-migration. This is the only way to catch crawl errors, sudden indexing drops, or 404 spikes early enough to fix before they compound into a real ranking loss.

The actual timeline this takes

Doing all of this properly is not a weekend project once real traffic and rankings are on the line — URL mapping and redirect testing alone deserves as much time as the front-end rebuild itself, even though it's the part with zero visual output to show for it.

I recently went through this exact migration for capareach.com itself — happy to talk through specifics in the comments, or more at capareach.com.