Blog Management

Taking over a blog – the starting audit and a plan for the first three months

The first month is an inventory: before I write anything new, I need to know what's already on the blog, what earns traffic, what competes with what and what's blocking growth. Without that it's easy to publish a post that takes traffic away from one of your own articles.

The result is an inventory sheet where every post gets a decision: keep, update, merge, or remove with a redirect. The criteria for those decisions are in the post on content decay.

Plan for the first quarter

The blog's technical foundation – template, archives, pagination and dates

The blog template decides how Google and AI crawlers see every post, so a template bug repeats on every page at once. As a developer I fix it myself instead of leaving a list of recommendations for someone else.

• Dates. Google's documentation on publication dates recommends a visible, labelled date ("Published", "Updated") plus datePublished and dateModified in structured data that match the visible date. The date should describe when the page was published or updated, not the event the post covers.
• Author. Every post has a byline linking to an author page, and in JSON-LD the author is a reference to a single Person entity, in line with Google's Article structured data recommendations.
• Archive pagination. According to Google's documentation, every page of a post list should have its own URL, links to the next pages in plain a href tags and its own canonical, not a canonical pointing to page one. Google no longer uses rel="prev" and rel="next".
• Categories and tags. I treat categories as topic pages with a short intro and links to the key posts. Tags with one or two posts get merged or noindexed, because they create hundreds of near-empty pages.
• Internal links in the template. A related-posts module and a link to the service assigned to the category, rendered in HTML rather than loaded by a script after interaction. Google says plainly that every page you care about should have a link from at least one other page on your site.
• Performance and rendering. I check the post template for Core Web Vitals and whether the content is in the HTML without running JavaScript.

The technical details are in the posts on Core Web Vitals and JavaScript SEO. If the problems go beyond the blog, I handle them in a technical SEO audit.

The editorial system – calendar, statuses and style rules

An editorial system is the set of tools and rules that stops the blog from depending on one person's memory: a calendar describing every post in full, clear statuses and written style rules. You get access to it, and it stays with you after we stop working together.

Fields in the publishing calendar

Post statuses

1. Idea – a topic from research, not yet approved.
2. Approved – signed off by you in the monthly plan.
3. Brief – structure, questions and sources ready.
4. Writing – the draft is in progress, with an interview if needed.
5. Review – with the expert or approver.
6. Ready – revised, with images, metadata and links.
7. Published – live, with a publish date.
8. Due for review – after 90 days, or earlier if the data shows a drop.

Style rules live in one document: how to address the reader, words and promises that are off-limits in your industry, how to present numbers and sources, product naming. With several authors, that document, not endless edits, keeps the blog's voice consistent.

A month of blog management – who does what, and when

Each month has a fixed rhythm: plan and approval at the start, writing and publishing in the middle, updates and the report at the end. Your role comes down to a few decisions at set points, not constant supervision.

Posts don't all go out in one week. With several articles a month I space them out, and I plan seasonal pieces early so they're indexed before interest peaks.

New posts or updates – how I split the monthly budget

The number of articles in a month is the sum of new posts, updates and merges, and I set the mix each month based on the data. In a month when several important articles are losing traffic, updating them comes before new topics.

The order in which I allocate work

1. Posts tied to your key services that are losing clicks. They already have history and links, and every loss means fewer enquiries.
2. Duplicates and cannibalisation. Merging two weak posts into one usually does more than a third post on the same topic.
3. Missing cluster pieces around the main service. Questions clients look up before buying that the blog doesn't answer yet.
4. Posts with high impressions and low CTR. A new title and a better first paragraph are often enough.
5. New topics for earlier stages of the decision. They build reach and first contact with the brand, but their effect on enquiries is slower.

For me an update means a real change: new data, a missing section, corrected sources, a new example. Only then does the updated date change on the page and in the structured data.

Post quality control – what I check before and after publishing

Every post goes through the same checklist before publishing, and some checks keep running automatically afterwards. That way a mistake in one post or in the template doesn't sit there for months until someone notices.

Before publishing

• One H1, a title and meta description unique across the site, main phrase at the start of the title.
• Every number has a primary source with publisher and year, and the source links work.
• The post has a first-hand element and expert sign-off where the topic calls for qualifications.
• Links to the pillar, cluster posts and the service with descriptive anchors, plus at least one link to the new post from older articles.
• Images with descriptive file names and alt text.
• Valid JSON-LD with the author and dates matching the page.

After publishing, automatically

On my own site I run two automated checks in CI, and I suggest the same setup to clients when their infrastructure allows it:

• An SEO check on every site change: for each URL in the sitemap it verifies one H1, a unique title and description, a self-referencing canonical, reciprocal hreflang, valid JSON-LD, no broken internal links and no orphan pages.
• A weekly check of source links across all blog posts, because sources disappear or move over time. 404, 410 and 5xx errors are flagged for fixing; bot blocks (such as 403 or 429) are warnings, because they don't mean the page is gone.

How the blog leads to enquiries – paths, CTAs and links to the offer

A blog brings enquiries when every post has an assigned service and a natural path to it at the point where the reader has the problem, not just a banner in the footer. I design this together with the topic plan, not after publishing.

• A post-to-service map is part of the calendar, so every new article has its target page from day one.
• A link to the service in the body, in the section describing the problem that service solves, with a descriptive anchor.
• A related-service module in the post template, chosen by category.
• GA4 key events for forms, phone and email clicks, and clicks from the blog to offer pages, so the report shows which posts start the paths that end in an enquiry.

Traffic from AI assistants lands on the blog too. How to separate it out in GA4 and server logs is in the post on measuring traffic from ChatGPT and Perplexity.

Distribution after publishing – LinkedIn, newsletter and short video

A post that only goes to search has no readers for its first few weeks. So I turn each article into several shorter pieces for the channels you already have, adapted to each one, instead of pasting the same link everywhere.

• LinkedIn: one argument from the post, developed over a few paragraphs, with the link in a comment or at the end. Ideally from the expert's profile, not only the company page, because it also builds their recognition.
• Newsletter: a short summary with one takeaway and a link, collected from the month's posts.
• Short vertical video: the post summarised in under a minute. That's what I do on my own blog, where every new post gets a video in Polish and English and its own cover.
• Graphics and tables: a diagram or table from the post as a standalone social asset.

How to automate turning one piece into many channels without losing the brand's voice is covered in the post on social media automation with AI. The role of the expert's profile in AI visibility is in the post on expert personal branding, and video in YouTube and AI visibility. Posts with strong visuals can also earn traffic from Google Discover.

The monthly report – what's in it and which decisions follow

The monthly report has one job: show what worked, what didn't and what that means for next month. So every part of it ends with a decision, not just a chart.

The report comes with next month's plan for approval. Traffic from AI Overviews and AI Mode is counted in Search Console's regular performance report, so I check presence in AI answers separately, as described in the AI visibility audit guide.

Guest, sponsored and AI-assisted posts on your blog – where the limits are

You can publish partner articles, sponsored posts and AI-assisted content on a company blog, but each has limits set out in Google's policies. I keep to them, because breaching them affects the whole site, not one post.

In Google's policy, the host's editorial oversight is one of the factors weighed for third-party content, but on its own it doesn't decide compliance. So whether I accept a partner's article depends first of all on whether it's written for your readers. More on the rules for AI content in the post on scaled content abuse, and on paid placements on external sites under link building strategy.

Changing provider or CMS – how not to lose traffic in a handover

When a blog moves from an agency, a freelancer or an in-house team, most traffic is lost through URL changes, bulk deletions and lost access. Before I change anything, I secure what works.

Handover checklist

1. Access on company-owned accounts: CMS with admin rights, Search Console, GA4 and, if needed, hosting and DNS. The accounts should belong to the company, not the previous provider.
2. A copy of content and media: an export of posts, the image library and SEO settings from plugins or CMS fields.
3. A list of URLs with traffic and external links, so none of them disappears without a redirect.
4. Existing editorial materials: the calendar, style rules, the list of experts and approved sources.
5. A no-URL-changes rule: in the first weeks I don't change the URL structure or delete posts in bulk. Merges and removals happen only after the audit, always with a 301 redirect, or a 410 where there's no equivalent.

If the handover also means moving the blog to a new CMS or domain, that's a migration, which I run using the procedure from SEO migration. I can also build a blog from scratch if the company doesn't have one yet. If you need a plan first without an ongoing engagement, start with a content marketing strategy; single articles are available as SEO copywriting.