Do you share what you learn as both a blog post and a rule?

You spend a weekend getting something working and write it up as a detailed blog post. Six months later a colleague hits the same problem, but the lesson is buried halfway down a dated post they never find. Or it goes the other way: someone pastes the whole tutorial into a rule, and nobody reads past the first screen.

A blog post and a rule do different jobs, so when you learn something worth sharing, share it as both:

• The blog post is the full story - How you landed where you did: the context, what you tried, the full examples, the code and the results. It's yours, so it builds your personal brand
• The rule is the best practice that came out of it - Short and punchy: here's the best practice, move on

Link them both ways and everyone wins. Rule readers get a real worked example, blog readers get the best practice in a few lines, both pages get backlinks, and the rules stay grounded in real work.

When to do it

• A rule already exists - When your post follows a practice that's already a rule, link to the rule from the post, then add your post to the rule's "Learn more" section so the link goes both ways
• No rule exists yet - When part of a new post is a practice that holds beyond your project, create the rule while you're writing the post, and link the two to each other

Keep the rule to one topic

A rule should explain the why, not the how, and it should cover one specific topic. Anything that isn't that topic, such as setup steps, wiring and implementation detail, goes in the blog post. If it's a separate practice worth sharing, make it its own rule. Otherwise the rule creeps in scope and the main point gets lost.

❌ Figure: Bad example - The rule is the whole tutorial, so the one practice it's about is lost

✅ Figure: Good example - The rule covers one practice, and the setup lives in the blog post

Let the blog post tell the whole story

The blog post is where the detail lives, so don't trim it to look like a rule. Share the full examples: the context, every step (including the gotchas and what you tried first), real code and screenshots, the trade-offs and the results. It's the story of how you got to the best practice, and it's published under your name. If the post grows too big, split it into multiple posts.

When the best practice changes, update the rule

If the rule already has a good example and you've found a better way, don't add yours alongside it. Replace it: your approach becomes the good example, and the previous one becomes a bad (or OK) example, so readers can see what changed. The blog post explains why.

Open the blog post with the rule

Work the rule into the opening of the post: say there's a rule on the topic, sum it up in a sentence, then carry on with the detail. Avoid a link tacked on at the end, or wording that makes the post sound like an afterthought to the rule.

❌ Figure: Bad example - The rule link is an afterthought at the end of the post

✅ Figure: Good example - The post opens with the rule and its one-line summary, then continues with the detail

End the rule with a link to the blog post

Finish the rule with a "Learn more" section that links to the post, so readers who want to implement it can find the worked example.

✅ Figure: Good example - The rule's Learn more section points to the post for the how-to

Linking both ways also helps Google see the two pages as one topic, so both rank better.

Use company branding on the rule

Rules are company best practices. If your blog post has diagrams or images in your personal branding, rebrand them in the company's colours and logos before you add them to the rule. You're welcome to use the company-branded versions on your blog too.