Kowal_Blog is a blog module for Magento 2 designed differently from classic blog extensions. Instead of building a separate post system, separate categories, and separate routing, the module leverages the power of the Magento catalog.

Blog categories are standard catalog categories, and a blog post is a product of the special type blog_post. This allows the blog to work closely with Magento mechanisms the store already has and that are well integrated with the frontend, SEO, store views, cache, and administration.

Unique concept

The most important feature of the module is the use of the Magento catalog as a content publishing engine.

The module adds a new product type:

blog_post

The blog_post type is based on the behavior of a virtual product, but it is not intended for sale. The post does not render price, cart, stock information, or shopping elements. From Magento's perspective, however, it remains a catalog entity, so it can use existing catalog features.

This approach combines two things:

• the editorial nature of a blog,
• the technical capabilities of the Magento catalog.

Why it matters

Many blog modules create a separate world next to Magento: separate post tables, separate categories, separate routing, separate SEO, and separate integrations. This often means more code, more exceptions, and more places that need to be maintained.

Kowal_Blog takes the opposite direction. It uses what Magento already does well:

• catalog categories,
• product-category relationships,
• EAV attributes,
• store views,
• URL rewrites,
• meta title and meta description,
• sitemap,
• cache,
• page layouts,
• product images,
• translations,
• standard admin forms.

As a result, the blog is not a separate add-on, but a natural part of the Magento store.

Business benefits

Consistent SEO with Magento

Posts use Magento's native SEO fields:

• url_key,
• meta_title,
• meta_description,
• meta_keyword.

The module also generates structured data tailored to blog content, such as BlogPosting, CollectionPage, ItemList, and BreadcrumbList. At the same time, it removes product structured data where a post should not be treated as a sales product.

Better use of store categories

Blog categories are catalog categories. The administrator indicates one category as the blog root, and its subcategories become blog categories.

This makes it possible to create a logical content structure, for example:

• Blog,
• Blog / Guides,
• Blog / News,
• Blog / SEO,
• Blog / Magento.

Less separate infrastructure

The module does not require a separate blog category model or a separate base post model. This limits the amount of custom code and reduces the risk of conflicts with Magento mechanisms.

A familiar workflow for the administrator

A blog post is created similarly to a product. The administrator works in a familiar Magento form, but with attributes tailored to content:

• publication date,
• author,
• post format,
• tags,
• difficulty level,
• content source,
• featured post.

Store views and translations

Because the post content is based on product attributes, you can use Magento's standard mechanisms for per-store-view values.

The post lead uses the native:

short_description

The main post content uses the native:

description

This simplifies translations and maintenance of multilingual content.

Module features

Blog Post product type

The module adds the blog_post product type, based on virtual product behavior. The type is intended for content publishing, not for sale.

Blog Post attribute set

During installation, a Blog Post attribute set is created, containing native Magento fields and additional editorial fields.

The module uses existing Magento attributes where it makes sense:

• name as the post title,
• short_description as the lead,
• description as the content,
• image as the main image,
• url_key as the URL,
• native meta fields for SEO.

Blog categories from the Magento catalog

In the module configuration, the administrator indicates the main blog category. This category is the blog homepage, and its subcategories are blog categories.

Post list

The module supports several list display variants:

• list,
• 2-column grid,
• 3-column grid,
• 4-column grid.

Each variant can display the post image, title, publication date, author, lead, and a link to the post.

Post view

The post page renders content as an article, not as a sales product. The post template shows:

• title,
• publication date,
• author,
• main image,
• lead,
• full content,
• tags.

Blog sidebar

The module provides a blog sidebar with blocks:

• blog categories,
• recent posts,
• tags.

The sidebar works with native Magento layouts:

• 1column,
• 2columns-left,
• 2columns-right.

Forcing the page layout

The administrator can set a separate layout for:

• blog categories,
• the post page.

This allows the blog to have a different layout than standard product categories.

Blocking elements from other modules

In many stores, additional blocks appear on product pages, for example lead time, supplier icons, comparison, wishlists, or stock information.

The module allows you to specify the names of layout blocks that should be removed only in the blog context. This makes it possible to keep a clean article view without affecting regular product pages.

Structured data

The module generates structured data appropriate for a blog:

• BlogPosting for a post,
• CollectionPage and ItemList for lists,
• BreadcrumbList for navigation.

This is important because a post is technically a Magento product, but for search engines it should be an article.

Who this module is for

The module is a good choice for Magento stores that want to run a blog without building a separate content system.

It is particularly well suited for:

• stores that work heavily with SEO,
• multilingual stores,
• projects with an extensive catalog,
• brands publishing guides and expert content,
• implementations where the blog should be an integral part of the store, not a separate add-on.

The key advantage

The biggest advantage of the module is that it does not try to replace Magento with a separate blog CMS. Instead, it uses the Magento catalog as a solid foundation for content.

Thanks to the blog_post product type, the blog gains the flexibility of editorial content while also benefiting from Magento's mature catalog mechanisms.

Migration from popular Magento blogs without losing SEO value

In many Magento stores, the blog has been running for years, but its current technology is becoming less convenient to maintain. Over time, there is a need to simplify the architecture, make better use of Magento's native mechanisms, and organize content without manually rewriting hundreds of posts.

Kowal_Blog solves this problem thanks to a migration mechanism from existing blog modules to a new model based on the Magento catalog.

This means that changing the blog does not have to mean losing previous editorial work or risking a sharp drop in search visibility.

What migration provides

The most important value for the client is simple: content that already exists can be transferred to the new solution without building everything from scratch.

Migration makes it possible to preserve and organize:

• blog posts,
• categories,
• tags,
• basic SEO data,
• publication structure,
• relationships between content and categories,
• URL history needed for redirects.

In practice, this means shorter implementation time, lower editorial risk, and a lower cost of moving to a new solution.

Support for well-known Magento blogs

The migration mechanism was prepared with real Magento implementations in mind, where several well-known blog extensions are most commonly encountered.

Currently supported migrations are from:

• Amasty Blog,
• Magefan Blog.

This is important because these are the solutions often found in stores that developed the blog independently of the Magento catalog and now want to move it to a more consistent model.

Migration without manually rewriting content

One of the greatest advantages is that there is no need to manually recreate the blog.

Instead of:

• copying texts post by post,
• recreating the category structure,
• rewriting tags,
• manually correcting dozens or hundreds of URLs,

you can perform a controlled migration to Kowal_Blog.

For the client's team, this means less operational work, and for the project, greater predictability.

Protection of existing SEO

When migrating a blog, one key question most often arises: what will happen to the existing URLs?

This is very valid, because old posts often:

• already have organic traffic,
• are indexed in Google,
• have external links,
• are used in marketing materials,
• are connected to campaigns or newsletters.

That is why the migration mechanism in Kowal_Blog includes creating redirects for known post and tag URL structures. This makes it possible to move to a new URL model without leaving users and search engine crawlers on broken pages.

Additionally, the system generates reports on completed redirects and a separate URL collision report, so the implementation team can immediately see which paths were handled automatically and which require a decision.

A better foundation for further store development

Migration is not just a one-time data transfer. It is also a way to organize the foundation on which the store will continue to operate.

After migration, the blog moves to a model that uses Magento's native mechanisms, such as:

• catalog categories,
• store views,
• URL rewrites,
• EAV attributes,
• standard Magento SEO,
• Magento admin forms.

This simplifies long-term development and reduces the number of separate, custom layers that need to be maintained.

Option to prepare migration on client request

Not every store uses one of the most popular modules. Some implementations run on older extensions, custom solutions, or modified versions of modules available on the market.

That is why the migration mechanism was designed to be extensible.

This means that in addition to ready-made support for well-known Magento blogs, it is also possible to prepare migration:

• from another commercial blog module,
• from the client's custom solution,
• from a custom data structure created in a specific project,
• from a version of an extension that was previously modified for a given store.

From a sales perspective, this is a very important advantage. The client is not limited only to a list of ready-made integrations. If a custom blog is running in the store, a dedicated migration path can be prepared for its specific data and business process.

Who this option is especially valuable for

Migration of a blog to Kowal_Blog will be especially valuable for:

• stores with a large number of articles,
• brands that regularly publish SEO content,
• multilingual projects,
• companies planning to rebuild the blog without losing existing traffic,
• stores that want to simplify Magento architecture and reduce the number of parallel content systems.

The sales argument, directly

The client is not buying only a new blog module here.

They are buying the ability to move from the current solution to a model that is more consistent with Magento:

• without manually rewriting content,
• while preserving the value of existing content,
• with control over redirects,
• with a report of completed operations,
• with the option to prepare a dedicated migration if the current blog operates in a custom way.

This shortens the path from the decision to change to the actual launch of the new blog and significantly lowers the barrier to entry for stores that already have a publication history.