---
title: "Blog/Article Crafting Guide"
slug: "blog-article-crafting-guide"
updated: 2026-10-27T23:12:51Z
published: 2026-10-27T23:12:51Z
canonical: "ims-handbook.cenosco.com/blog-article-crafting-guide"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://ims-handbook.cenosco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Blog/Article Crafting Guide

### AI Preamble

Denis Tkalec drafted the article below to provide some guidelines on creating articles/blogs for Cenosco.

To help use the document,

[](https://cdn.document360.io/e492a0e0-a4ba-4aca-8fc6-76b95f91fdf3/Images/Documentation/cenosco-article-writing.skill?sv=2026-02-06&spr=https&st=2026-10-28T11%3A05%3A55Z&se=2026-10-28T12%3A05%3A55Z&sr=c&sp=r&sig=KU4ABudZgnHTYzidmtm%2FPnPnN1Ik%2BW76lSK75KoTblQ%3D)cenosco-article-writing3.54 KB[](https://cdn.document360.io/e492a0e0-a4ba-4aca-8fc6-76b95f91fdf3/Images/Documentation/cenosco-article-writing.skill?sv=2026-02-06&spr=https&st=2026-10-28T11%3A05%3A55Z&se=2026-10-28T12%3A05%3A55Z&sr=c&sp=r&sig=KU4ABudZgnHTYzidmtm%2FPnPnN1Ik%2BW76lSK75KoTblQ%3D)

A .skill file is basically a zip file that Claude uses to package the resources necessary for each skill. In the case above, it only contains a SKILL.md file. If you want to see how one of these files is structured, see the SKILL.md file below:

[](https://cdn.document360.io/e492a0e0-a4ba-4aca-8fc6-76b95f91fdf3/Images/Documentation/SKILL.md?sv=2026-02-06&spr=https&st=2026-10-28T11%3A05%3A55Z&se=2026-10-28T12%3A05%3A55Z&sr=c&sp=r&sig=KU4ABudZgnHTYzidmtm%2FPnPnN1Ik%2BW76lSK75KoTblQ%3D)SKILL7.48 KB[](https://cdn.document360.io/e492a0e0-a4ba-4aca-8fc6-76b95f91fdf3/Images/Documentation/SKILL.md?sv=2026-02-06&spr=https&st=2026-10-28T11%3A05%3A55Z&se=2026-10-28T12%3A05%3A55Z&sr=c&sp=r&sig=KU4ABudZgnHTYzidmtm%2FPnPnN1Ik%2BW76lSK75KoTblQ%3D)

Now, onto the actual article:

## 0. Do Deep Research (Before You Write a Single Word)

Most people make the mistake of jumping straight into writing. **Don't be most people.**

**Step 1: Analyze the Top 10 Google Results** Type in your main keyword and see what's already ranking. Ask yourself:

- What subheadings are they using?
- How long are the articles?
- What does the content cover that you plan to write about?
- Where are the gaps you can improve upon?

This tells you **what Google considers relevant** for that search.

**Step 2: Look Up Terms You Don't Understand** If you come across a technical term, statistic, or concept that's unclear, **look it up**. Don't guess. Readers (and Google) spot inaccuracies immediately.

**Step 3: Create a "Content Brief"** Before writing, jot down:

- 5–7 key points you'll cover
- Sources and data you'll use
- Target keywords you want to rank for
- The "content gap" – what others missed that you'll include

**Why This Matters for SEO:** Google rewards content that demonstrates **E-E-A-T** (experience, expertise, authoritativeness, trustworthiness). Research is the foundation of all four.

## 1. Every article must follow the “problem–solution–IMS” structure

**Each blog post must follow this global structure**:

- **Problem:** clearly explain the challenge or pain point engineers face (e.g., RCM being too resource‑intensive).
- **Solution:** describe the method or approach that solves it (e.g., strategy libraries, risk‑based segmentation).
- **How to solve it with IMS:** show **concretely** how the IMS RCM tool (or IMS ecosystem) supports that solution (features, workflows, reports).

This structure keeps the article **focused, practical, and aligned with your sales and support messaging**.

## 2. Use long‑tail, low‑competition keywords

He should **not** target generic terms like **“Reliability Centered Maintenance”** unless absolutely necessary,

- Instead, focus on **long**‑**tail, more specific phrases** such as:
  - “Reliability Centered Maintenance risk‑based prioritization”
  - “RCM maintenance strategy libraries for centrifugal pumps”
  - “how to reduce RCM resource demand with digital tools”

This makes it easier to **rank for specific search intents** and **match how engineers actually phrase questions**.

## 3. Think about the title first, not at the end

**The title often shapes the whole article, so don’t write it as an afterthought.**

- Ensure it contains the main keyword naturally (e.g., “Reliability Centered Maintenance with strategy libraries”).
  - Keep it short, clear, and SEO‑friendly (ideally under 60 characters) so it fits search results and passes Yoast checks.
  - Make it relevant and precise so readers immediately know what the article is about and trust it.

## 4. Keep paragraphs and subsections short and crisp

Tell him to:

- Limit **paragraphs to 4–6 sentences**;
- Keep **each section under a subheading short enough** that Yoast does not flag it as “too large” (in practice this usually means **no more than 2–3 paragraphs per H3/H2**).

If a section grows too long, **split it into two subsections** with more descriptive headings. This improves **readability on mobile**, **Yoast scores**, and **engineering**‑**style clarity**.

## 5. Use active, concise, engineering‑style English

Engineers dislike fluff, marketing‑style phrases, and “salesy” language.

- Encourage **direct, technical wording**:
  - Use **“you” and “we”** where appropriate, but keep it **professional and factual**.
  - Avoid exaggerated claims; instead, say **“can reduce effort”**, **“typically reduces time”**, **“may improve consistency”**.

This makes the tone **respectful of reader expertise** and **more credible**.

## 6. Mention target roles and audiences in the text

Instead of a generic “for maintenance professionals,” encourage him to **name specific roles**:

- “This approach is useful for **integrity teams, corrosion engineers, reliability engineers, and maintenance planners**.”

This helps:

- **Google** and readers understand **who benefits**;
- Positions IMS as a **practical tool for concrete engineering functions**, not a generic marketing concept.

## 7. Use outbound links only when truly useful

External links should **support authority**, not accidentally promote competitors.

- Prioritize linking to:
  - **Industry standards** (ISO, API, etc.),
  - **Academic or professional references** (e.g., Moubray RCM II, Cenosco MEI article),
  - **Public statistics or data sources** (e.g., government or industry reports).

If there is **no strong external reference**, he can **skip** the outbound link rather than forcing a link to a competitor or weak site.

## 8. Add images, charts, and tables when possible

- When writing about **numbers, comparisons, or processes**:
  - **Note in the draft** that a **chart or table would help** (e.g., “This could be shown as a bar chart: tasks vs. failure modes per equipment type”).
  - Clearly describe **what data to plot** (axes, categories, labels) so the designer can create it.
- He can **embed simple tables directly in the article** (e.g., “number of tasks per asset type,” “MEI ranges”), but more complex diagrams should be **described and handed off to the designer**.

This keeps the content **engineer**‑**friendly** and **easily visualizable** without over‑promising visuals.

## 9. Use bold for key technical terms, not for marketing

Use **bold sparingly and only for technical concepts**:

- **Reliability Centered Maintenance (RCM)**
- **maintenance strategy libraries**
- **risk**‑**based segmentation**
- **Maintenance Efficiency Indicator (MEI)**
- **Technical Authorities**

Avoid bolding generic marketing phrases; bold should highlight **concepts engineers actually look up**, not sales slogans.

From a readability point of view, **light but consistent bolding** makes the text easier to scan without overwhelming the eye.

- Keep in mind that **one or two bolded terms per paragraph** is usually enough; more than that starts to look like highlighter abuse rather than real emphasis.

## 10. Repeat core keywords naturally, not aggressively

Keywords must appear, but **not stuffed**.

- Use your main **long**‑**tail phrases 1–2 times per 80–120 words**.
- Embed them in **real examples**:
  - “In a risk‑based RCM prioritization exercise, the team first segments assets by criticality.”

This keeps the text **natural and technical**, while still helping **SEO**.

## 11. Use internal links to our product pages and articles

He should **link from blog posts back to relevant software pages and documentation**:

- To **IMS RCM product page**, **strategy library features**, **MEI reports**, **handbook sections**, etc.
- Anchor text should be **descriptive and technical**:
  - “See the IMS RCM tool’s strategy library feature.”
  - “For an overview of MEI calculation, see the IMS Handbook.”

This strengthens **your internal site architecture** and **guides users toward product content**.

## 12. Build authority with concrete numbers and examples

Engineers trust **numbers and specifics**, not vague claims.

- 
  - “Typical reduction in workshop days when using strategy libraries.”
  - “Number of tasks per equipment type before and after simplification.”
  - “How many failure modes per asset are typically covered.”

These numbers can be **based on real cases or conservative estimates**, but must be **plausible and realistic**.

## 13. Use clear H2 and H3 headings aligned with your abstract logic

Headings should mirror the **logical flow** of the RCM discussion:

- **Why RCM Can Be Resource**‑**Intensive**
- **Can RCM Be Simplified Without Losing Effectiveness?**
- **How Maintenance Strategy Libraries Reduce Effort**
- **Risk**‑**Based Segmentation of Assets**
- **When Full RCM Is Still Necessary**

Each H2 should be **self**‑**descriptive** and contain **the keyword in a natural way if possible.**

## 14. Keep sentences short and active

Yoast often flags long, complex sentences.

- Aim for **mostly under 20–22 words per sentence**.
- Use **active voice**:
  - “The team identifies failure modes during FMEA.”
  - “The facilitator leads multi‑day workshops.”

This improves **readability scores** and keeps the **tone professional and technical**.

## 15. Use checklists for implementation steps

When explaining how to apply an idea, **turn it into a short checklist**:

- Example:
  - “How to implement resource‑efficient RCM:
    1. Segment assets by risk.
    2. Define basic task sets for low‑critical equipment.
    3. Use strategy libraries for common equipment types.
    4. Reserve full RCM for safety‑critical assets.”

Checklists are **highly practical** and **easy to follow** in real projects.

## 16. Write one or two “quotable” lines

Help him craft **1–2 strong, engineer**‑**friendly sentences** that others might reuse or quote:

- “Reliability‑Centered Maintenance is not about doing less thinking, but about applying structured thinking more efficiently.”
- “Using strategy libraries shifts effort from repeated analysis to repeatable, traceable decisions.”

These lines can support **social sharing and backlinks** without sounding like marketing.

## 17. End with a clear call to action tied to IMS

The conclusion should **not just repeat the text**. Ask the reader to **take a concrete next step**, aligned with how you usually close articles on **cenosco’s site** (e.g., via an **“Ask for demo”**‑style button, not just soft “learn more”):

- **“To see how this approach works in practice, request a demo of the IMS RCM tool.”**
- **“You can also explore how IMS RCM supports simplified RCM workflows through strategy libraries and digital workflows.”**

This turns the article into a **practical gateway to your product**, matching the **CTA**‑**style you already use on Cenosco** (demo, booking, or contact‑driven prompts).

## 18. Align keyword strategy with your product pages

He should **coordinate keywords with your existing product**‑**page strategy**:

- Main product pages already target **broader terms** (e.g., “RCM software,” “Reliability Centered Maintenance”).
- Blog posts should focus on **more specific, long**‑**tail phrases** that **support and feed** those pages, not compete with them.

This keeps your **SEO ecosystem consistent** and avoids cannibalization.

## 19. Maintain a consistent, engineering‑tone style across posts

Tell him to **keep the same style** from article to article:

- Direct, technical language;
- Clear structure (problem → solution → how IMS helps);
- Concrete examples, numbers, and references.

This builds **branded authority** over time and makes your blog feel like a **reliable engineering resource**, not a random blog.