Skip to Content
HandbookMarketingContentWriting blogs

Writing blogs

Anyone at SucuriLabs can write a blog post, and we’d love you to! You don’t need permission to start writing. The marketing team reviews posts before they’re published.

This page covers the basics, whatever your role or topic. If you’re an engineer writing about something you built, tell us how it works, why you made those decisions, and what you learned along the way.

Why write a blog?

Useful content is part of our marketing strategy. A good blog gives someone a reason to read, learn something, and remember us.

It’s also good for your career! Writing about your work lets other people see how you think and what you know.

Finally, sometimes it’s just useful to explain a topic once and have a link to share instead of repeating yourself dozens of times. It can start a conversation with a customer or explain how something works at SucuriLabs.

Is my idea worth writing about?

Our audience is the people we build for: security engineers, security analysts, and IT teams investigating and stopping email threats. That’s a group you have a lot in common with, so if you’re excited enough to write something they’d find useful, it’s probably worth a blog. If you’re still not sure, share the idea with the marketing team.

Should I write a blog, a newsletter, a tutorial, or a doc?

  • Blog: An opinion, story, guide, or comparison. Most common.

  • Newsletter: Updates, useful reading, or a practical takeaway for readers who want to hear from us. Coordinate with the marketing team before writing an issue.

  • Tutorial: A step-by-step guide to doing something, such as investigating a suspicious email in SucuriLabs. Give the reader a clear path to follow.

  • Docs: The reference for how the product works, its settings, and the steps to use it. Keep these accurate as the product changes.

Tips for writing good blogs

Read the style guide for writing and formatting, the voice and tone guide for how we sound, and brand foundations for what we care about. The rest of this section is specific to blogs.

Titles

Having something interesting to say matters more than the title – you can usually find a title to fit a good idea, but no title saves a boring one. That said, the title is what someone judges in search results, in a feed, and in an AI answer, so it’s worth spending time on. Examples of titles that could work:

  • “An email can pass authentication and still be malicious” challenges an assumption and makes you curious about why.

  • “How to investigate an email pretending to be your supplier” names a specific problem and promises a useful explanation.

  • “What we learned building our incident triage workflow” promises first-hand experience, including the decisions and mistakes behind the work.

Avoid being vague or boring (“Our approach to email security”). If a generic B2B SaaS company would write it, we shouldn’t, but don’t put being funny or clever above being clear. If a title promises numbers or results, the post needs to back them up.

How it’ll reach people

Decide who the post is for and how it’ll reach them before you write it, not after you publish. It influences what you write and how you explain it. Think about:

  • LinkedIn – a good place to share a strong opinion, something we learned, or a useful explanation through our personal and company accounts.

  • Search – practical guides and comparisons that answer questions people are looking up. Use the words they’d use to describe the problem.

  • Sharing it directly – a post can answer a prospect’s question, explain a feature to a customer, or help someone investigate an email threat.

Drafting

  • Preview as you write. Read the post as a reader would see it. Check the headings, paragraphs, screenshots, and code examples in the website preview.

  • Write it yourself. AI can help with brainstorming, research, outlines, and finding weak spots in an argument. You write the sentences. Our no AI slop rule applies to blogs too.

  • Add useful links. Link to relevant docs, other posts, and sources that support your claims. Make the link text tell the reader what they’ll find.

  • Check the mechanics. Follow the style guide for sentence case, punctuation, and media. Give the reviewer a post you’ve already read through.

Submitting for review

All blogs must be reviewed by the marketing team before publishing.

Before you submit, make sure you have:

  1. A post that follows the style and voice guides, with sources for factual claims and technical examples you’ve checked.

  2. The metadata and author information required by the website repo. Use an existing post as a reference for the format.

  3. Any images or videos the post needs, following the media guidelines. Ask the marketing team early if you need help with artwork.

  4. A preview you’ve checked for formatting, working links, and readable media.

To submit, create a pull request in the SucuriLabs website repo. Put the post alongside the existing blog posts and follow the repo’s file format. Include a short description of who the post is for and what you want the reader to learn. Ask the marketing team for a review.

If you’ve already discussed the post with someone on the marketing team, ask them to review it. Work through the feedback and check the preview again after making changes.

Once it’s approved, follow the website repo’s publishing process. Agree with the marketing team on how and when to share it.

Resources

Last updated on