Forem: David@Opace

My Guide to Using Structured Data for SEO & eCommerce

David@Opace — Sat, 09 May 2026 12:53:04 +0000

With rich search results, People Also Ask, AI overviews, and Shopping results taking up more real estate than ever in Google search results, not to mention the importance of being found on LLMs like ChatGPT, it's clear that SEO is no longer just about matching words on a page.

Search engines like Google and Bing, shopping providers and AI systems need clear facts about products, brands, reviews, prices, availability, shipping and returns. For eCommerce websites in particular, structured data gives those systems a cleaner way to read what shoppers can already see.

Structured data will not rescue weak content, poor products or messy site architecture. It's not a magic ranking switch. What it can do is help search engines understand pages, qualify pages for rich results, improve product visibility and make business information easier to interpret. This article follows the supplied brief and focuses on structured data for SEO, schema markup, eCommerce, rich results and AI search.

What is structured data?

Structured data is a standardised way to describe the content of a web page using labelled, machine-readable information.

A normal product page might show a product name, image, price, review score and “in stock” message. A shopper understands this easily. Search engines can often infer the same meaning, but inference is not the same as clarity. Structured data tells them directly: this is the product name, this is the price, this is the brand, this is the current availability.

For eCommerce SEO, that clarity matters because product pages contain facts that change often. A price can shift during a promotion. A size can sell out. A review count can increase. Structured data gives search engines a consistent way to process that information across many pages.

Google says it uses structured data to understand page content and gather information about entities such as people, books and companies. It also uses eligible markup to display rich results in Google Search.

Structured data vs unstructured data

Unstructured data is normal page content: paragraphs, images, headings, buttons, badges and layout.

Structured data is labelled information that follows a defined format.

For example:

Page content	Structured meaning
“£89.99”	Product price
“In stock”	Availability
“4.7 from 214 reviews”	Aggregate rating
“Blue, size 9”	Product variant
“Free returns within 30 days”	Return policy

This is why structured data helps search engines understand pages more reliably.

Structured data vs schema markup

Structured data is the concept. Schema markup is the code used to express it.

Schema.org is the shared vocabulary used to describe things such as Product, Offer, Review, Organization, LocalBusiness and Article. JSON-LD is the format most commonly recommended for adding schema markup to a website.

Schema.org defines Product as any offered product or service, while Offer describes the offer to sell, rent, stream, repair or otherwise provide something. (Product - Schema.org)

What is schema markup in SEO?

Schema markup is code added to web pages so search engines can understand the entities and facts on those pages.

On an eCommerce product page, schema markup can describe:

Product name
Product image
Description
Brand
SKU
GTIN
Price
Currency
Availability
Condition
Reviews
AggregateRating
Shipping details
Return policy

For SEO, the value is not that schema markup “forces” rankings. The value is that it gives search engines a clearer model of the page. A product page becomes easier to distinguish from a category page, a blog post, a review guide or a brand page.

That matters more as search becomes richer. Search results now include product snippets, merchant listings, image results, shopping panels and AI-generated answers. Clean structured data helps feed those systems with clearer facts.

Structured data, rich results, rich snippets and featured snippets compared

Term	Meaning	Controlled by schema?	Example
Structured data	Machine-readable page data	Yes	Product, Offer, Article
Schema markup	The vocabulary and code used	Yes	JSON-LD Product schema
Rich result	Enhanced Google result	Eligible via schema	Price, stock, rating
Rich snippet	Older term for enhanced snippets	Partly	Review stars
Featured snippet	Extracted answer box	No direct control	Paragraph/list answer

Rich results are the enhanced search listings most businesses notice. A plain result might show a title and meta description. A rich product result may show price, availability and review information.

Structured data can make a page eligible for rich results, but it does not guarantee display. Google’s general structured data guidelines say pages must follow its content and quality policies to qualify for rich result appearance.

Does schema markup help SEO rankings?

Schema markup is not a direct ranking shortcut. Adding schema to a weak page will not suddenly make it outrank stronger competitors.

Its SEO benefit is practical rather than magical.

Structured data can:

Improve eligibility for rich results
Help search engines classify content
Support product visibility in shopping surfaces
Improve how listings appear in search results
Create clearer Search Console reporting
Strengthen entity understanding for AI search

The sceptical view often seen in SEO forums is partly fair: schema alone will not fix poor content, weak links, thin product pages or technical crawl problems.

But dismissing schema markup completely is also short-sighted. For eCommerce sites, structured data sits close to revenue because it communicates price, stock, reviews, product identity and merchant policies.

Why structured data is especially useful for eCommerce SEO

eCommerce sites are data-heavy. They also change constantly.

A product may have:

Several colours
Multiple sizes
A parent product
Variant URLs
Sale pricing
Review data
Shipping options
Return policies
GTINs
SKU values
Availability changes

Without structured data, search engines must interpret all of that from visible page content alone.

Google’s Product structured data documentation says product variant structured data can help Google understand which products are variations of the same parent product, and that product snippets and merchant listings support product variants. (Product - Google for Developers)

Product visibility across Google surfaces

Product structured data can support visibility in:

Google Search
Google Images
Shopping experiences
Merchant listings
Product snippets
Visual search experiences

For merchants, Google’s Merchant Center guidance also notes that accurate, correctly formatted product data helps match products to the right queries and avoid display issues.

Reducing ambiguity around products

A search engine needs to know whether a page is:

Selling a product
Reviewing a product
Listing many products
Explaining a product category
Describing a local store
Publishing an editorial article

Schema markup helps make that distinction clearer.

A category page should not pretend to be a single product. A buying guide should not pretend to be a merchant listing unless users can actually buy the item from the page. These details affect trust and eligibility.

Main schema types eCommerce sites should understand

Product schema

Product schema is used for individual product detail pages. It can describe name, image, description, brand, SKU, GTIN, offers, ratings and reviews.

Product schema is the base layer for many eCommerce rich result opportunities.

Offer schema

Offer schema sits inside Product schema and describes the current commercial offer.

It usually includes:

Price
Currency
Availability
URL
Condition

If price or availability is wrong, the structured data becomes unreliable. That can lead to warnings, lost eligibility or poor user experience.

Merchant listing structured data

Merchant listing structured data supports richer shopping experiences. Google’s merchant listing guide focuses on Product structured data requirements for merchant listings and points editorial product review pages towards product snippet markup instead. (Merchant Listings - Google for Developers)

Merchant listings may use product facts such as:

Price
Availability
Shipping
Returns
Product images
Merchant identity

Product snippet structured data

Product snippets are often more relevant for editorial or review-led pages.

For example, a blog article comparing “best trail running shoes” might use product snippet structured data where valid. A merchant product page should focus on Product and Offer data for the item being sold.

Google’s product snippet guidance recommends adding required properties, following guidelines and validating code with the Rich Results Test. (Product Snippets - Google for Developers)

ProductGroup and product variant schema

ProductGroup describes a group of products that vary only in defined ways such as size, colour or material. (ProductGroup - Schema.org)

This is useful for products like:

Trainers available in five colours
Sofas available in several fabrics
T-shirts available in multiple sizes
Jewellery available in different metals

Useful properties include:

hasVariant
isVariantOf
variesBy
productGroupID

Google’s product variant documentation includes ProductGroup and Product guidance for variant relationships. (Product Variants - Google for Developers)

Review and AggregateRating schema

Review and AggregateRating schema must reflect genuine, visible user content.

AggregateRating represents the overall rating based on several ratings or reviews. Schema.org lists AggregateRating as usable with Product, Offer, Organization, Place, Service and other types. (AggregateRating - Schema.org)

Do not mark up reviews that are fake, hidden, copied or not representative of the page.

Organization schema and eCommerce policy markup

Organization schema identifies the business behind the website.

It can include:

Name
Logo
Contact details
Social profiles
Customer service information
Shipping policy
Return policy

Google’s Product structured data documentation also recommends structured data defining eCommerce business policies nested under Organization markup.

BreadcrumbList schema

BreadcrumbList schema helps show page hierarchy.

Example:

Home → Men’s Footwear → Running Shoes → Trail Running Shoes

This supports both users and search engines.

WebSite and SearchAction schema

WebSite schema describes the website. SearchAction can describe internal search functionality where suitable.

This is usually sitewide rather than page-specific.

Article or BlogPosting schema

Blog posts, guides and SEO resources should use Article or BlogPosting schema.

For this article, the page itself would naturally use Article or BlogPosting, plus BreadcrumbList and Organization.

LocalBusiness schema

LocalBusiness schema suits eCommerce brands with:

Physical shops
Showrooms
Collection points
Local service areas
Click-and-collect locations

It should not be used if there is no genuine local business presence.

FAQPage schema caveat

FAQs are still helpful for users, but FAQ rich results are no longer a reliable SEO tactic for standard commercial sites.

Google reduced FAQ rich result visibility in 2023, limiting it mainly to authoritative government and health websites.

Current third-party reporting also indicates Google has moved further towards removing FAQ rich result visibility from Search in 2026, so FAQ content should be written for users first rather than treated as a rich-result shortcut.

Product schema example for an eCommerce product page

Here is a simple JSON-LD example:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Men's Trail Running Shoes",
  "image": [
    "https://example.com/images/trail-running-shoes.jpg"
  ],
  "description": "Lightweight trail running shoes for mixed terrain.",
  "sku": "TRAIL-001",
  "gtin13": "1234567890123",
  "brand": {
    "@type": "Brand",
    "name": "PeakMotion"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/mens-trail-running-shoes",
    "priceCurrency": "GBP",
    "price": "89.99",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "124"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Alex Morgan"
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5"
      },
      "reviewBody": "Comfortable on muddy trails and surprisingly light."
    }
  ]
}

Only include ratings and reviews if they are genuine and visible on the page. The same rule applies to price, availability and product identifiers.

Product schema for variants: size, colour and material

Product variants are where many eCommerce schema implementations become messy.

A single parent product may have:

4 colours
8 sizes
3 materials
Separate stock levels
Different images
Variant-specific URLs

If every variant is marked up as an unrelated product, search engines may not understand the relationship. ProductGroup helps solve this.

Single URL with selectable variants

Some sites use one product URL where users select size or colour from dropdowns.

This can work well when:

Variant information is visible
JavaScript does not hide key details
JSON-LD updates accurately
Canonicalisation is clean

One URL per variant

Other sites create separate URLs for each variant.

This can work when:

Each variant has unique value
Variant URLs are crawlable
Canonicals are handled carefully
Schema links variants back to the parent group

Dynamic JavaScript-only markup

If structured data is generated only after client-side JavaScript runs, updates to price and availability may be delayed or missed.

For fast-changing product data, server-rendered JSON-LD is usually safer.

Category pages, collection pages and product listing pages

Category pages should be treated differently from product pages.

Recommended schema often includes:

BreadcrumbList
ItemList where suitable

A category page can list products, but it is not usually itself a Product.

Avoid marking up every listed item as though it is the primary product of the page unless the implementation matches Google’s guidance for that feature.

Schema does not replace good category SEO. Category pages still need:

Crawlable product links
Useful copy
Strong internal linking
Clear filters
Sensible canonical tags
Fast loading
Helpful sorting and faceting

A beautifully marked-up category page with thin content and broken filters will still struggle.

How to add schema markup to your website

JSON-LD, Microdata and RDFa compared

Format	How it works	Best suited to
JSON-LD	Script block containing structured data	Most modern SEO use cases
Microdata	Markup embedded in HTML elements	Older template-level implementations
RDFa	Attribute-based semantic markup	More specialised semantic web use

JSON-LD is usually easiest to maintain because it sits separately from visible HTML.

Adding schema in WordPress and WooCommerce

WordPress and WooCommerce sites often use SEO plugins, product review plugins or theme-level schema.

This can work well for basic use cases, but check:

Duplicate Product schema
Missing GTINs
Incorrect brand fields
Review plugin conflicts
Variant handling
Outdated template markup

WooCommerce stores often need custom fields for GTIN, brand and advanced merchant data.

Adding schema in Shopify

Shopify themes often include Product schema by default.

Problems usually appear when apps add extra schema on top of the theme.

Check:

Theme JSON-LD
App-generated schema
Duplicate Product entities
Variant output
Product feed consistency
Missing return or shipping details

For Shopify SEO, structured data should be audited whenever themes or product apps change.

Adding schema in custom and Next.js websites

Custom and headless sites need more developer involvement.

Good practice includes:

Generating JSON-LD server-side
Pulling data from the same product source as the visible page
Keeping schema aligned with stock systems
Testing before deployment
Monitoring templates after release

Next.js websites should avoid stale client-generated product data where price and stock change often.

When plugins are enough vs when custom schema is needed

Plugins may be enough for:

Small brochure sites
Basic blogs
Simple product catalogues
Standard Article schema
Basic Organization schema

Custom schema is often needed for:

Product variants
International stores
Multiple currencies
Complex shipping rules
Marketplaces
Headless builds
Advanced review systems
Large eCommerce catalogues

How to test and validate schema markup

A sensible workflow:

Identify the page type.
Choose the correct Schema.org type.
Check Google’s supported rich result documentation.
Add required properties.
Add relevant recommended properties.
Validate using the Rich Results Test.
Validate syntax with Schema Markup Validator.
Inspect the live URL in Search Console.
Deploy to a small test group.
Monitor reports before scaling.

Google Merchant Center also recommends testing schema.org implementation with Search Console or the Rich Results Tool.

Structured data testing should happen before and after launch. A staging test alone is not enough because live rendering, canonical tags, blocked scripts and indexing behaviour may differ.

Common schema markup mistakes to avoid

Marking up hidden content

Structured data should match what users can see.

Hidden reviews, invisible FAQs or unavailable product attributes create trust issues.

Fake reviews or ratings

Do not add star ratings unless the reviews are genuine, visible and relevant to the item.

Product schema on the wrong page type

Product schema belongs on pages where a specific product is the main content.

Category pages, search pages and editorial pages need different treatment.

Missing required properties

A product without price, currency or availability may fail eligibility checks for rich results or merchant features.

Incorrect price, currency or availability

This is common during promotions. If a visible product price changes, schema and feeds should change too.

Duplicate or conflicting schema

Themes, plugins and apps can all output schema. Multiple Product entities with different prices or ratings can confuse search engines.

JavaScript-generated markup for fast-changing data

Client-rendered schema can work, but server-rendered markup is often more reliable for stock and pricing.

Relying on FAQ schema for rich results

FAQ content is still useful. FAQ rich results should not be treated as a dependable commercial SEO tactic in 2026.

Adding every possible schema type

More schema is not always better. Use the most specific relevant type.

How to measure the SEO impact of structured data

Structured data should be measured against business outcomes, not just validation tools.

Track:

Rich result eligibility
Valid and invalid item counts
Product snippet reports
Merchant listing reports
Impressions
Clicks
CTR
Average position
Organic revenue
Assisted conversions
Landing page performance

Search Console is the main place to monitor structured data health. Many eligible structured data types generate enhancement reporting where Google can identify valid and invalid markup.

For eCommerce, compare page templates before and after implementation. A template-level improvement may affect hundreds or thousands of URLs, so isolate changes where possible.

A good measurement plan might compare:

Product pages with improved schema vs product pages unchanged
Variant pages before and after ProductGroup markup
Category pages with improved BreadcrumbList and ItemList
Organic revenue from product landing pages
CTR changes for product-rich queries

Structured data and AI search and GEO

AI search has made structured data more valuable, but not because it guarantees chatbot citations.

It helps because AI systems need clear entity facts.

Structured data can clarify:

What the product is
Who makes it
Who sells it
Whether it is available
What it costs
Which reviews apply
Which policies apply
How products relate to variants

That supports knowledge graph-style understanding.

However, schema markup alone does not guarantee inclusion in AI Overviews, generative answers or chatbot responses. AI systems also rely on visible content, authority signals, third-party mentions, product feeds, business consistency and user trust.

For eCommerce brands, the strongest approach combines:

Accurate Product schema
Clean Organization schema
Consistent Merchant Center data
Helpful product content
Real reviews
Clear policies
Reliable brand information across the web

Structured data is one part of AI SEO and GEO, not the whole recipe.

Recommended schema checklist by page type

Page type	Recommended schema	Main purpose
Homepage	Organization, WebSite, SearchAction	Brand identity
Product page	Product, Offer, AggregateRating/Review, BreadcrumbList	Product rich results and merchant eligibility
Variant product page	ProductGroup, Product, Offer	Variant understanding
Category page	BreadcrumbList, ItemList	Hierarchy and list clarity
Blog article	Article or BlogPosting, BreadcrumbList	Content understanding
Review guide	Article, Product snippet, Review where valid	Editorial product visibility
Local store page	LocalBusiness, Organization, BreadcrumbList	Local entity information
FAQ/help page	FAQPage only where suitable	User support, limited rich-result value

Final structured data implementation checklist

Before publishing schema markup across an eCommerce website, check:

Is the schema type specific to the page?
Is every marked-up fact visible to users?
Are required properties present?
Are recommended properties included where genuinely available?
Are product price, availability, SKU and GTIN accurate?
Are images crawlable and indexable?
Is there one coherent schema graph?
Are plugins, apps and themes creating duplicates?
Has the Rich Results Test passed?
Has Schema Markup Validator passed?
Has the live URL been inspected?
Are Search Console reports being monitored after deployment?

Structured data works best when it is treated as part of technical SEO maintenance, not a one-off task.

Final thoughts: structured data is now part of modern SEO for websites and eCommerce alike

Structured data is no longer a “nice to have” technical extra for eCommerce websites. It is a practical way to make product, brand and business information clearer for search engines, shopping platforms and AI systems.

The most important point is that schema markup should describe the truth of the page. It should not exaggerate, hide missing information or mark up content that users cannot see. Product prices, stock status, reviews, shipping details and return policies all need to match the visible page and stay accurate over time.

For smaller websites, basic Product, Offer, Organization, BreadcrumbList and Article schema may be enough to create a stronger technical foundation. For larger eCommerce stores, structured data needs to be planned more carefully around product variants, feeds, templates, review systems, apps, plugins and international selling.

The sites that benefit most from structured data are usually the ones that treat it as part of a wider SEO and content strategy. Clean schema works best alongside useful product pages, accurate product feeds, strong internal linking, fast templates, trustworthy reviews, clear policies and consistent brand information.

Schema markup will not guarantee rich results, higher rankings or AI search visibility on its own. What it can do is reduce ambiguity. It helps search engines and AI systems understand what a page is about, what a product is, who sells it, what it costs, whether it is available and how it relates to the wider business.

As Google search results become more visual, commercial and AI-assisted, eCommerce websites need to make their information as easy as possible for machines to interpret and as useful as possible for shoppers to trust. Structured data sits directly between those two goals, making it one of the most important technical SEO foundations for modern online stores.

About me: Agency owner since 2008 with a passion for technology and SEO. I've helped over 100 small and large businesses with their SEO strategies and implementation. Check out my profile on dev.to for more articles, see our SEO services, or drop me a message 👇🏻

David@OpaceFollow

UK based web developer, open-source and AI enthusiast, and technology writer. Founder of https://opace.agency since 2008.

The Complete Astro CMS Guide: Comparing Git-Based, Hybrid & Headless JS & Jamstack CMS Platforms

David@Opace — Wed, 14 Jan 2026 16:14:56 +0000

Executive Summary

In my hunt for an SEO-friendly, headless CMS and modern Jamstack alternative to WordPress, I found Astro. It’s a modern web framework built around pre-rendered HTML, partial hydration, and an islands-based architecture that keeps JavaScript to an absolute minimum, while still supporting React, Vue, Svelte and other popular UI frameworks where needed.

The part of Astro’s tagline that always caught me off guard was the “content-driven websites” claim. Coming from a PHP and WordPress background, that phrase immediately suggests a built-in CMS, something Astro clearly is not, at least not on its own.

Finding a CMS for Astro

This report provides an in-depth analysis of 13 major CMS platforms that integrate with Astro, evaluated across 20 critical feature areas. The analysis uses a standardised 0–5 scoring methodology to help developers and content teams select the most appropriate CMS for their specific project requirements.

Broken down, these fall into three categories:

10 x Headless CMS
2 x Git-Based CMS
1 x Hybrid CMS

What is "Headless CMS"?

Put simply, a Headless CMS separates content management from presentation, giving you complete flexibility in how and where you deliver your content. Rather than being tied to a specific frontend, channel or theme, a headless CMS acts as a content repository that serves your content through APIs.

This architecture has become the industry standard for modern web development because it enables teams to build faster, scale more efficiently, and adapt to changing requirements without being locked into a single presentation layer.

Key benefits:

Separates content management from presentation
Provides content via APIs (REST, GraphQL, etc.)
No built-in frontend/theme system
Frontend is completely decoupled
Can deliver to any channel (web, mobile, IoT, etc.)

What is "Git-Based CMS"?

A Git-Based CMS takes a fundamentally different approach by storing content directly in your Git repository as files (Markdown, JSON, or YAML) rather than in a traditional database. This approach appeals to developers who prefer version control-based workflows and want content to live alongside their code.

What is "Hybrid CMS"?

A Hybrid CMS combines elements of traditional CMS architecture with headless capabilities, offering both a built-in frontend/theme system and API access for decoupled deployments. These platforms give you options—you can use their default frontend if you prefer, or build your own using their APIs.

Comparison Summary

Aspect	Headless CMS	Git-Based CMS	Hybrid CMS
Architecture	API-first, decoupled	File-based, Git-native	Both built-in & API
Best For	Modern web apps, Astro	Static sites, docs	Flexible deployments
Learning Curve	Medium	Low for developers	Medium
Non-technical Users	Good support	Poor support	Good support
Scalability	Excellent	Limited	Good
Cost	Variable (SaaS/self-hosted)	Low	Variable
Flexibility	Maximum	Medium	High

Why a Headless CMS is a Great Choice?

Headless CMS platforms offer unmatched flexibility and control. You can use any frontend framework (React, Vue, Astro, etc.), deploy to any hosting provider, and easily adapt to new technologies without replacing your entire CMS.

This approach eliminates vendor lock-in, enables faster development cycles, and provides better performance. For teams building modern web applications, especially with static site generators like Astro, a headless CMS is the natural choice.

Choosing the Best Astro CMS

Whether you're building a blog, documentation site, or complex content platform, this comparison report will help you choose the right Jamstack CMS for your Astro project.

Based on comprehensive feature evaluation, Contentful emerges as the highest-scoring platform (90/100) with enterprise-grade capabilities, followed by DatoCMS (86/100) and Payload CMS (81/100). However, the best choice depends on your specific needs: Strapi excels for open-source deployments, Storyblok for visual editing experiences, Decap CMS for Git-based workflows, and StudioCMS for Astro-native solutions.

Scoring Methodology

Each Astro CMS is evaluated on a 0–5 scale across 20 feature areas:

0 = Not realistically possible
1 = Possible but painful/fragile
2 = Doable with heavy custom work
3 = Solid via plugins/apps
4 = Strong out-of-the-box
5 = Excellent + mature + editor-friendly

WordPress Alternative Score

Each CMS is also scored on how well it serves as a Jamstack alternative to WordPress, considering:

Admin panel usability and familiarity for non-developers
Content management workflows (similar to WordPress editor)
Plugin/extensibility ecosystem
Built-in features (media, SEO, users, roles)
Learning curve for WordPress users
Overall feature parity with WordPress

Astro CMS Features Compared

Feature	Strapi	Storyblok	Decap CMS	DatoCMS	StudioCMS	TinaCMS	Ghost	Contentful	Payload
Content Modelling	5	4	3	5	4	3	2	5	5
Relational Data	5	4	2	5	3	2	2	5	5
Front-end Editing (Visual)	2	5	1	3	3	5	2	3	2
Live Preview	3	5	3	4	4	5	3	4	3
Workflow & Approvals	4	4	1	5	2	2	3	5	3
Versioning & Rollback	4	4	5	5	3	5	4	5	4
Roles & Permissions	5	4	2	5	3	2	3	5	4
Multilingual Support	4	5	3	5	3	3	3	5	4
Media / DAM Capability	4	4	2	4	3	2	3	5	4
SEO Controls	4	4	3	4	4	3	5	4	4
API & Delivery Options	5	5	2	5	4	3	4	5	5
Extensibility	5	4	3	4	4	3	4	5	5
TOTAL SCORE	78	79	52	86	64	57	64	90	81

1. Strapi - Best Open-Source CMS

Repository: strapi/strapi

Stars: 71,000+

Type: Open-source Headless CMS

Overall Score: 78/100

WordPress Alternative Score: 7.5/10

Strapi is the leading open-source headless CMS built entirely in JavaScript/TypeScript. It provides a fully customizable admin panel and powerful REST/GraphQL APIs, making it ideal for developers who need complete control over their content infrastructure.

Key Strengths:

Exceptional content modelling and relational data support (5/5)
Granular roles and permissions system (5/5)
Excellent API and delivery options with both REST and GraphQL (5/5)
Highly extensible plugin system (5/5)
Strong open-source community with active development

Limitations:

Limited visual/front-end editing capabilities (2/5)
Requires more setup and configuration than SaaS alternatives
Steeper learning curve for non-technical editors

Best For:

Developers seeking complete control, complex content models, and open-source solutions with enterprise-grade features. Teams transitioning from WordPress who want more developer control.

Screenshots:

2. Storyblok - Best Visual Editing Experience

Repository: storyblok/storyblok-js

Stars: 40+

Weekly Downloads: 26,000 (via @storyblok/astro)

Type: Headless CMS with Visual Editor

Overall Score: 79/100

WordPress Alternative Score: 8/10

Storyblok is a headless CMS renowned for its exceptional visual editing experience. It allows content creators to edit directly on the website with live preview, making it ideal for teams that prioritise user experience and visual content management.

Key Strengths:

Outstanding visual editing and live preview (5/5 each)
Excellent multilingual support (5/5)
Strong API and delivery options (5/5)
Intuitive interface for non-technical content editors
Real-time collaboration features
Most WordPress-like editing experience in headless CMS space

Limitations:

SaaS-only model with subscription costs
Less control over infrastructure and customisation
Versioning capabilities slightly behind competitors (4/5)

Best For:

Teams prioritising editor experience, visual content management, and real-time collaboration. Ideal for marketing-driven organisations and WordPress users seeking a modern alternative.

Screenshots:

3. Decap CMS - Best for Git-Based Workflows

Repository: decaporg/decap-cms

Stars: 18,800+

Type: Git-based CMS

Overall Score: 52/100

WordPress Alternative Score: 3/10

Decap CMS (formerly Netlify CMS) is a lightweight, Git-based CMS that stores content directly in your repository. It's ideal for static site generators and developers who prefer version control-based workflows.

Key Strengths:

Exceptional versioning and rollback capabilities (5/5) - leverages Git
Strong performance and caching (4/5)
Free and open-source
Simple deployment model
Perfect for static site workflows

Limitations:

Limited content modelling flexibility (3/5)
Weak relational data support (2/5)
No visual editing (1/5)
Not suitable for non-technical users

Best For:

Static site generators, documentation sites, and teams comfortable with Git-based workflows. Best for smaller projects with simpler content structures and developer-focused teams.

Screenshots:

4. DatoCMS - Best for Enterprise Workflows

Repository: datocms

Stars: 166+ (react-datocms)

Weekly Downloads: 1,900 (via @datocms/astro)

Type: API-based Headless CMS

Overall Score: 86/100

WordPress Alternative Score: 7/10

DatoCMS is a premium API-based headless CMS that excels in content modelling, editor experience, and team collaboration. It offers a modern interface with powerful content structuring capabilities.

Key Strengths:

Exceptional content modelling and relational data (5/5 each)
Outstanding workflow and approval systems (5/5)
Excellent versioning and rollback (5/5)
Granular roles and permissions (5/5)
Strong multilingual support (5/5)
Enterprise-grade environments and deployment (5/5)

Limitations:

SaaS-only with premium pricing
Limited visual editing capabilities (3/5)
Smaller ecosystem compared to Strapi

Best For:

Enterprise teams, complex content structures, and organisations requiring sophisticated approval workflows and collaboration features. Teams moving from WordPress who need more powerful content modelling.

Screenshots:

5. StudioCMS - Best Astro-Native Solution

Repository: withstudiocms/studiocms

Stars: 685+

Weekly Downloads: 1,200 (via studiocms)

Type: Astro-native Headless CMS

Overall Score: 64/100

WordPress Alternative Score: 6/10

StudioCMS is a dedicated CMS built specifically for the Astro ecosystem. It's designed from the ground up by the Astro community, offering seamless integration with Astro projects and Astro DB.

Key Strengths:

Native Astro integration with zero friction
Built on Astro's architecture and conventions
Growing community support within Astro ecosystem
Good content modelling capabilities (4/5)
Solid live preview and performance (4/4)
Simpler setup than Strapi for Astro projects

Limitations:

Younger project with smaller feature set
Limited visual editing (3/5)
Weaker workflow/approval systems (2/5)
Smaller ecosystem and fewer integrations (3/5)

Best For:

Astro-first projects, teams already invested in the Astro ecosystem, and projects that prioritise framework-native solutions. Good for teams wanting a simpler alternative to heavyweight CMS platforms.

Screenshots:

6. TinaCMS - Best for Visual Git-Based Editing

Repository: tinacms/tinacms

Weekly Downloads: 48 (via astro-tina)

Type: Git-based Headless CMS with Visual Editing

Overall Score: 57/100

WordPress Alternative Score: 5/10

TinaCMS is an open-source headless CMS that combines Git-based content storage with visual editing capabilities. It's designed for developers who want Git version control with a better editor experience.

Key Strengths:

Excellent visual editing and live preview (5/5 each)
Strong Git-based versioning (5/5)
Open-source and free
Developer-friendly with TypeScript support
Markdown-first approach

Limitations:

Limited content modelling compared to enterprise solutions (3/5)
Weak relational data support (2/5)
Limited workflow/approval features (2/5)
Smaller ecosystem and fewer integrations (2/5)

Best For:

Developers seeking visual editing with Git workflows, Markdown-based content, and projects that need developer control with editor-friendly interfaces.

Screenshots:

7. Ghost - Best for Publishers

Repository: TryGhost/Ghost

Type: Blogging Platform & Membership CMS

Overall Score: 64/100

WordPress Alternative Score: 6.5/10

Ghost is a modern blogging platform and membership CMS focused on content creators and publishers. It excels at content publishing, membership management, and newsletter features.

Key Strengths:

Outstanding SEO controls (5/5) - built for publishers
Strong versioning and rollback (4/5)
Excellent URL and routing control (4/4)
Built-in membership and subscription management
Modern, clean interface
Better for publishers than WordPress

Limitations:

Limited content modeling (2/5)
Weak relational data support (2/5)
No visual editing (2/5)
Primarily designed for blogs/newsletters, not complex content structures

Best For:

Publishers, bloggers, newsletter platforms, and membership-based content sites. Ideal for teams transitioning from WordPress who want a more modern, focused platform.

Screenshots:

8. Contentful - Best Enterprise CMS

Repository: contentful

Type: Enterprise Headless CMS

Overall Score: 90/100

WordPress Alternative Score: 6/10

Contentful is an enterprise-grade headless CMS that provides the most comprehensive feature set among all evaluated platforms. It's designed for large organisations with complex content needs.

Key Strengths:

Exceptional content modelling and relational data (5/5 each)
Outstanding workflow and approval systems (5/5)
Excellent versioning and rollback (5/5)
Granular roles and permissions (5/5)
Superior multilingual support (5/5)
Enterprise-grade environments and deployment (5/5)
Powerful search capabilities (4/5)
Exceptional multi-site/multi-tenancy (5/5)
Best-in-class DAM capabilities (5/5)

Limitations:

Premium pricing (enterprise-focused)
Steeper learning curve
Overkill for smaller projects
Limited visual editing (3/5)

Best For:

Enterprise organisations, large-scale projects, complex content structures, and teams requiring sophisticated governance and multi-site management. Not recommended for WordPress users seeking a simple alternative.

Screenshots:

9. Payload CMS - Best Customizable Open-Source

Repository: payloadcms/payload

Weekly Downloads: 15 (via astro-payload-local-loader)

Type: Open-source Headless CMS

Overall Score: 81/100

WordPress Alternative Score: 7.5/10

Payload is a modern, open-source headless CMS built with Node.js that provides excellent content modelling, extensibility, and developer experience. It offers both REST and GraphQL APIs with a customizable admin interface.

Key Strengths:

Exceptional content modelling and relational data (5/5 each)
Custom schemas and migrations (5/5)
Excellent extensibility and plugin system (5/5)
Outstanding custom apps and admin UI extension (5/5)
Strong API and delivery options (5/5)
Highly customizable admin interface
Active development and growing community

Limitations:

No visual editing (2/5)
Limited workflow/approval features (3/5)
Smaller ecosystem than Strapi
Requires more setup than SaaS alternatives

Best For:

Developers seeking powerful open-source solutions with excellent extensibility, custom admin interfaces, and full control over infrastructure. Teams wanting to build custom admin experiences.

Screenshots:

10. Sveltia CMS - Modern Git-Based Alternative

Repository: sveltia/sveltia-cms

Weekly Downloads: 20 (via astro-sveltia-cms)

Type: Git-based Headless CMS

Overall Score: 58/100

WordPress Alternative Score: 3/10

Sveltia CMS is a modern, lightweight Git-based CMS that serves as a successor to Netlify CMS (Decap CMS). It maintains compatibility while offering improved performance and modern features.

Key Strengths:

Git-based versioning and rollback
Lightweight and fast
Modern, clean interface
Open-source and free
Good performance optimisation
Better than Decap CMS in many areas

Limitations:

Limited content modelling
Weak relational data support
No visual editing
Smaller ecosystem
Not suitable for non-technical users

Best For:

Static site generators, teams familiar with Decap CMS, and projects seeking a modern Git-based alternative for developer-focused teams.

Screenshots:

11. Kontent.ai - Enterprise Collaboration CMS

Repository: kontent-ai

Weekly Downloads: 14 (via @simply007org/kontent-ai-astro)

Type: API-based Headless CMS

Overall Score: 72/100

WordPress Alternative Score: 6/10

Kontent.ai is an enterprise headless CMS focused on content teams and developers. It emphasises real-time collaboration and structured content management.

Key Strengths:

Strong content modelling capabilities
Real-time collaboration features
Good multilingual support
Comprehensive API options
Strong team collaboration tools

Limitations:

SaaS-only with premium pricing
Limited visual editing
Smaller ecosystem

Best For:

Enterprise teams, collaborative content environments, and organisations needing strong team features and structured content management.

12. Flotiq

Repository: flotiq/flotiq-astro-sdk

Weekly Downloads: 9 (via @flotiq/flotiq-astro-sdk)

Type: Headless CMS

Overall Score: 60/100

WordPress Alternative Score: 4/10

Overview: Flotiq is a lightweight headless CMS designed for developers who need simplicity and ease of integration.

WordPress Comparison: Flotiq is simpler than WordPress but lacks many of WordPress's features and ecosystem. It's better suited for developers than for non-technical users.

Key Strengths:

Simple setup and integration
Good API support
Developer-friendly
Lightweight

Limitations:

Smaller feature set
Limited visual editing
Smaller ecosystem
Not suitable for complex workflows

Best For: Small to medium projects, developers seeking simplicity, and teams with straightforward content needs.

13. Spearly

Repository: spearly

Weekly Downloads: 83 (via astro-spearly)

Type: Headless CMS

Overall Score: 61/100

WordPress Alternative Score: 4/10

Overview: Spearly is a Japanese headless CMS platform with growing international adoption.

WordPress Comparison: Spearly is not positioned as a WordPress alternative. It's a specialised headless CMS with limited feature overlap with WordPress.

Key Strengths:

Good content modelling
API-first approach
Growing ecosystem
Japanese language support

Limitations:

Smaller international community
Limited documentation in English
Smaller feature set
Not suitable for WordPress migrations

Best For: Projects with specific Spearly requirements, Japanese-language content, and teams already using Spearly.

WordPress Alternative Comparison

CMS	WordPress Alternative Score	Best For
Storyblok	8/10	Visual editing, non-technical editors
Strapi	7.5/10	Developers, complex content, open-source
Payload CMS	7.5/10	Developers, custom admin interfaces
DatoCMS	7/10	Enterprise teams, workflows
Ghost	6.5/10	Publishers, bloggers, membership
StudioCMS	6/10	Astro projects, simpler alternative
Contentful	6/10	Enterprise, large-scale
Kontent.ai	6/10	Enterprise teams, collaboration
TinaCMS	5/10	Developers, Git workflows
Decap CMS	3/10	Static sites, developers
Sveltia CMS	3/10	Static sites, developers

Highest Overall Scores

Contentful (90/100) - Enterprise-grade with comprehensive features
DatoCMS (86/100) - Strong workflows and collaboration
Payload CMS (81/100) - Open-source powerhouse

Recommendation by Use Case

Large Scale & Enterprise CMS

Contentful (90/100) - Most comprehensive feature set
DatoCMS (86/100) - Excellent workflows and collaboration
Payload CMS (81/100) - Powerful open-source alternative

Open-Source CMS

Strapi (78/100) - Most mature and feature-rich
Payload CMS (81/100) - Modern alternative with excellent extensibility
TinaCMS (57/100) - Git-based with visual editing

Visual Editing CMS

Storyblok (79/100) - Best-in-class visual editor
TinaCMS (57/100) - Git-based with visual editing
Contentful (90/100) - Enterprise with visual capabilities

Git-Based Workflows

Decap CMS (52/100) - Lightweight and simple
TinaCMS (57/100) - Visual editing + Git
Sveltia CMS - Modern Decap alternative

Native Astro CMS

StudioCMS (64/100) - Built for Astro ecosystem
Strapi (78/100) - Strong Astro integration
Storyblok (79/100) - Excellent Astro support

Developer Experience

Payload CMS (81/100) - Extensible and customizable
Strapi (78/100) - Mature ecosystem
TinaCMS (57/100) - Git-friendly for developers

WordPress Users Seeking Alternative

Storyblok (8/10) - Most familiar visual editing experience
Strapi (7.5/10) - Similar admin interface, more control
Payload CMS (7.5/10) - Customizable, developer-friendly

Publishers & Content Creators

Ghost (6.5/10) - Purpose-built for publishers
Storyblok (8/10) - Visual editing, easy to use
DatoCMS (7/10) - Powerful workflows

Versioning & Rollback Support

Decap CMS (5/5) - Git-based
TinaCMS (5/5) - Git-based
Contentful, DatoCMS, Strapi (4-5/5) - Mature systems

Conclusion

Choosing the right headless CMS will always depend on the nature of the project and overall requirements. If content and SEO are important, then Asto is a clear modern web dev and Jamstack winner. For the backend CMS, this report lists 13 amazing platforms to consider, with Contentful, DatoCMS, Payload, Storyblok and Strapi being the highest overall scoring.

Contentful offers the most comprehensive feature set for enterprise needs, while Strapi remains the best open-source choice for teams seeking complete control. Storyblok excels for visual editing workflows and is the closest Jamstack equivalent to WordPress, DatoCMS for team collaboration, and StudioCMS for Astro-native solutions.

For WordPress Users Specifically:

If you're transitioning from WordPress to a Jamstack CMS stack using Astro, consider these factors:

Editor Experience: Storyblok provides the most familiar visual editing experience, closest to WordPress Gutenberg.
Admin Interface: Strapi and Payload CMS offer customizable admin interfaces that can replicate WordPress workflows.
Content Management: DatoCMS and Contentful provide more sophisticated content management than WordPress but with steeper learning curves.
Simplicity: Ghost is the best WordPress alternative if you primarily need blogging and membership features.
Developer Control: Strapi and Payload CMS give developers the most control, similar to WordPress with custom themes and plugins.

For most Astro projects, I would recommend evaluating your needs across the following criteria:

Budget & Licensing: Open-source (Strapi, Payload) vs. SaaS (Contentful, DatoCMS, Storyblok)
Editor Experience: Visual editing (Storyblok) vs. Traditional forms (Strapi, Contentful)
Content Complexity: Simple (Decap CMS) vs. Complex (Contentful, Payload)
Team Size: Solo developers (Decap CMS) vs. Enterprise teams (Contentful)
Workflow Requirements: Simple publishing vs. Approval workflows (DatoCMS, Contentful)
WordPress Familiarity: How important is it that the CMS feels like WordPress?

What are your thoughts about the 13 Astro CMS providers listed here? Have I missed any out, or do you have experience that would perhaps change the scoring? Please add a comment below. It would be great to get a discussion going to help developers understand what's available and make an informed decision.

About me: Agency owner since 2008 with hands-on experience maintaining over 200 WordPress sites. I now specialise in modern web architecture and helping teams migrate to headless CMS platforms like Astro. Check out my profile on dev.to for more articles, see our web design services, or drop me a message 👇🏻

David@OpaceFollow

UK based web developer, open-source and AI enthusiast, and technology writer. Founder of https://opace.agency since 2008.

Disclaimer

This report represents my research and understanding of these CMS platforms as of January 2026. However, CMS platforms are actively developed and features, pricing, and capabilities change frequently. Feature availability varies by pricing tier and license type—what's available in a free tier may differ significantly from enterprise plans. Always verify current information with each platform's official documentation and try free trials before deciding.

The Hidden Costs of WordPress Maintenance: A 15-Year Agency Perspective

David@Opace — Fri, 26 Sep 2025 14:01:24 +0000

Running a web agency since 2008 means I've seen the WordPress maintenance burden grow from manageable to overwhelming as the complexity of sites increases over time. What started as simple updates on basic brochure websites has become a complex mishmash of dependencies, security patches, and compatibility issues that eat into project budgets and client relationships.

Here's some real data on what WordPress maintenance actually costed in 2024 - and why many agencies are quietly moving clients to alternatives. If you've had experiences managing WordPress sites (good or bad), I'd love to hear from you in the comments below.

The Real Numbers: WordPress Maintenance Costs by Site Type

Based on industry data from multiple sources, here's what businesses actually pay for WordPress maintenance in 2024:

Site Type	Monthly Cost Range	Annual Cost
Basic Personal Sites	$10-50/month	$120-600/year
Small Business Sites	$50-200/month	$600-2,400/year
Medium Business Sites	$200-500/month	$2,400-6,000/year
Enterprise Sites	$500-2,000+/month	$6,000-24,000+/year

These aren't just hosting costs. This includes security updates, plugin management, backup monitoring, performance optimisation, and emergency fixes when something breaks.

What I've Tracked Over 15 Years

I maintain detailed records of client maintenance work. Here's what the data shows:

Security Updates: Average 2.3 hours per month per site

WordPress core updates: Monthly
Plugin updates: Weekly average of 8-12 plugins per site
Theme compatibility checks after updates
Emergency security patches when vulnerabilities are discovered

Performance Issues: Average 1.8 hours per month per site

Database optimisation and cleanup
Image compression and CDN management
Caching configuration updates
Page speed optimisation after plugin changes

Compatibility Problems: Average 1.2 hours per month per site

Plugin conflicts after updates
Theme breaking changes
PHP version compatibility issues
Server configuration adjustments

Emergency Fixes: 0-3 incidents per year per site

White screen errors after updates
Plugin security vulnerabilities requiring immediate attention
Database corruption from failed updates
Server crashes during high traffic

The Time Drain is Real

Let me share actual time logs from last month across 10 active WordPress sites:

3 hours updating plugins across all sites
1 hours troubleshooting a Yoast SEO conflict
1 hours emergency fix for WooCommerce payment issue
2 hours WordPress core updates and testing
2 hours optimising slow-loading sites after Elementor update
1 hours backup restoration after failed theme update
1 hours security patch installations
2 hours fixing broken contact forms after plugin update
1 hours database optimisation
2 hours monthly security scans and malware checks
1 hours performance audits and speed optimisation
1 hours client training on new admin interface changes

Total: 18 hours for 10 sites = 1.8 hours per site per month

At £90/hour agency rates, that's £162/month per site just for basic maintenance and fixes. This doesn't include changes, new feature development or design updates. To include only 2 hours per month for site changes, that brings the minimum WordPress maintenance contract to £342/month or £4,104/year.

The Plugin Dependency Problem

The average business WordPress site runs 20-30 plugins. Each plugin adds:

Security Risk: More code means more potential vulnerabilities
Performance Impact: Each plugin adds database queries and HTTP requests
Compatibility Issues: Updates can break other plugins or themes
Ongoing Costs: Many plugins now require annual licenses

Here's a typical small business site plugin list and annual costs (verified 2024-2025 pricing):

Security plugin (Wordfence Premium): $149/year
Backup plugin (UpdraftPlus): $70/year
SEO plugin (Yoast Premium): $119/year
Page builder (Elementor Pro): $60/year
Form plugin (Gravity Forms): $59/year
Analytics plugin: $39/year
Social sharing: $29/year

Total: $525/year in plugin licenses alone, before hosting or maintenance labor.

When Things Go Wrong

The real costs emerge when maintenance lapses or things break. See various scenarios below that highlight costs clients could incur:

Failed Update Cascade: A plugin update breaks another plugin, which crashes the site. Client loses 6 hours of sales, pays £540 in emergency fixes, and I spend 3 hours troubleshooting. Total impact: £1,200+ in lost revenue plus repair costs.

Security Breach: Outdated plugins lead to a malware infection. Cleanup requires: malware removal (8 hours), security audit (4 hours), backup restoration (2 hours), client notification and reputation management. Cost: £1,080 in labor plus potential legal liability and customer trust damage.

Database Corruption: A failed update corrupts the WordPress database. Backup restoration takes 4 hours, but the most recent backup is 2 weeks old, meaning 2 weeks of content changes are lost. Client loses data, I lose credibility, and recovery costs £360 in labor.

Performance Degradation: Unmanaged plugins accumulate database bloat. Site speed drops from 2 seconds to 8 seconds. Google rankings fall, organic traffic drops 40%, costing the client £2,000+ in lost leads over the next month. Performance optimisation requires 6 hours of work.

Hosting Bill Shock: Poorly optimised WordPress sites consume excessive resources. Hosting provider throttles the site or demands upgrade to premium tier. Client's monthly hosting jumps from £20 to £150 without warning.

These are scenarios based what we have seen happen. The pattern is clear: skipping £200/month in preventive maintenance often leads to £1,000-5,000 emergency repairs. It's like skipping car maintenance and then paying for an engine rebuild.

The Alternative Costs

Static sites require different maintenance:

Hosting: £0-20/month (Netlify, Vercel free tiers)
Security: Minimal - no database to hack
Updates: Content changes only, no core/plugin updates
Performance: Consistently fast without optimization
Emergency Issues: Rare, usually hosting-related

A typical static site maintenance contract:

Monthly content updates: 2 hours at £90/hour = £180
Annual hosting and domain: £120
Total annual cost: £2,280 vs £4-12,000 for comparable WordPress site

Why Agencies Don't Always Mention This

WordPress maintenance creates recurring revenue. A client paying £600/month for maintenance generates £7,200 annually with relatively predictable work.

Static sites generate less maintenance revenue but happier clients:

Fewer emergency calls
Consistent performance
Lower total cost of ownership
More time for strategic work vs. firefighting

Many agencies are shifting to value-based pricing rather than maintenance-heavy models.

The Migration Economics

Moving from WordPress to a static site involves upfront costs:

Content migration: 8-16 hours depending on site size
Design rebuild: 20-40 hours for custom themes
Testing and launch: 4-8 hours
Total: 32-64 hours at £90/hour = £2,880-8,460

This investment typically pays for itself within 12-18 months through reduced maintenance costs. And this is a worst-case scenario based on 100% manual development. These costs can be reduced down by as much as 80% using generative AI tools for coding, automation and development.

Making the Business Case

For business owners, the math is straightforward:

WordPress 5-Year Total Cost:

Maintenance and updates: £200/month × 60 months = £12,000
Plugin licenses: £525/year × 5 years = £2,625
Emergency fixes: £1,000/year × 5 years = £5,000
Hosting: £20/month × 60 months = £1,200
Total: £20,825

Static Site 5-Year Total Cost:

Migration: £5,000 (one-time)
Maintenance and updates: £100/month × 60 months = £6,000
Hosting: £10/month × 60 months = £600
Total: £11,600

Savings: £9,225 over 5 years (45% cost reduction), plus fewer headaches, better performance, and zero emergency incidents. Again, bear in mind that using modern AI tools (ChatGPT, Claude, GitHub Copilot) for migration and maintenance can reduce migration costs considerably, making the overall saving much greater.

When WordPress Still Makes Sense

WordPress remains the right choice for:

Complex E-commerce: Extensive product catalogs, user accounts, payment processing
Member Communities: User registration, forums, subscription content
Multi-author Publications: Editorial workflows, user roles, comment management
Frequent Content Updates: Daily publishing, multiple editors

For most business websites - information, services, portfolios - the maintenance overhead isn't justified.

The Future of Web Maintenance

The industry is moving toward:

Static-first Architecture: Build static, add dynamic features only when needed
Headless CMS: Separate content management from presentation
Serverless Functions: Handle dynamic features without server maintenance
AI-Driven Web Development: Using proficient models and agents like Claude Sonnet 4.5 to assist and automate web development
Modern Deployment: Git-based workflows with automatic builds

These approaches reduce maintenance to content updates and occasional feature additions.

Conclusion

After 15 years of WordPress maintenance, I can tell you the hidden costs add up quickly. Security updates, plugin conflicts, performance issues, and emergency fixes create an ongoing burden that many business owners don't anticipate.

The 2024 data shows maintenance costs ranging from $600-24,000 annually depending on site complexity. For most business websites, static alternatives offer 60-70% cost savings and even higher with the use of AI automation. And all this with better performance and reliability.

The question isn't whether WordPress can work - it obviously can, and we still love it for many projects. The question is whether the maintenance overhead matches your business needs and budget.

Analysis based on 15 years of client data, industry maintenance surveys, and cost comparisons from SpdLoad, WPBeginner, StateWP, and other 2024 sources.

About me: Agency owner since 2008 with hands-on experience maintaining over 200 WordPress sites. Currently specialising in static site migrations and modern web architecture. Check out my profile on dev.to for more articles, or if you want to stay in touch, you can follow Opace here.

David@OpaceFollow

UK based web developer, open-source and AI enthusiast, and technology writer. Founder of https://opace.agency since 2008.

Why Static Site Generators Beat WordPress for Small Business SEO

David@Opace — Fri, 26 Sep 2025 13:43:52 +0000

After working with a wide range of businesses during the past 15 years, I've promoted WordPress over all of the alternatives to our clients. We started out working with Joomla and Drupal back in 2008 but moved over to WP as our platform of choice from around 2014 onwards due to some of the amazing advancements and features introduced by plugin developers. Sadly, I've also seen it slowly lose its performance edge while static site generators (SSGs) gained ground. The numbers tell a story that WordPress advocates might not want to hear.

What does the data say?

The data from HTTP Archive and Chrome UX Report cited on astro.build gives us a clear picture. Only 44% of WordPress sites pass Core Web Vitals benchmarks, while Astro (unsurprisingly) leads the pack at 63%.

Here's what the 2024 data shows for Core Web Vitals passing rates:

Astro: 63% of sites pass
WordPress: 44% of sites pass
Gatsby: 42% of sites pass
Next.js: 27% of sites pass
Nuxt: 24% of sites pass

When nearly 60% of WordPress sites fail basic performance standards, we need to ask why small businesses are still choosing this platform for their primary web presence.

My personal experience

As an agency owner, developer and SEO, ensuring our websites load quickly and perform optimally has always been a top priority. As a general benchmark, I've always tried to ensure <2s full page load times on 4G and mobile core web vitals achieving a score 80+.

This used to be relatively straight-forward with plugins like WP Total Cache, WP-Optimize and my personal favourite, WP Rocket. If we threw in Cloudflare (the free version), even more complex sites did well. Later, we updated our infrastructure stack to include an expensive dedicated LiteSpeed Enterprise server running LiteSpeed Cache for WordPress.

However, with time, the WordPress sites started to grow more complex due to the number of plugins and customisations needed and it became a challenge to hit those scores of 80+ on core web vitals.

We then switched to Nitropack, an all-in-one CDN, compression and caching provider, which worked a treat due to their fancy JS/CSS delay tricks. All of a sudden 90-100 scores were possible again, but something felt uneasy with this approach, like we were trying to trick the system rather the build websites the right way.

Data from a recent study

A recent migration study by developer mfyz.com (https://mfyz.com/wordpress-to-astro-migration-performance-comparison) provides concrete data outlining what happened when they moved from WordPress to Astro.

His heavily optimised WordPress site (already using WP Rocket caching and Cloudflare) showed these improvements after switching:

Metric	WordPress	Astro	Improvement
Largest Contentful Paint	0.81s	0.44s	46% faster
SEO Score	86	100	Perfect score
HTML Size	38.9KB	10.9KB	72% smaller
JavaScript Load	13.4KB	5.3KB	60% reduction
CSS Load	67.2KB	6.6KB	90% reduction

These aren't small gains, it's a massive jump in performance.

Why this matters for small business SEO

Google's algorithm updates prioritise site speed and user experience. I know first-hand how quickly speed optimisation can improve organic rankings on search.

Core web vitals scores play an important role in this. When your WordPress site loads in 3-4 seconds while your competitor's static site loads in under 1 second, all else being equal, you're potentially loosing customers.

Consider these business implications:

Bounce rate: Every 100ms delay increases bounce rates by 7%
Conversion impact: Sites loading in 1 second have 3x higher conversion rates than sites loading in 5 seconds
Mobile performance: 53% of mobile users abandon sites that take longer than 3 seconds to load

*Sources:

Akamai Technologies State of Online Retail Performance Report (2017): https://www.akamai.com/newsroom/press-release/akamai-releases-spring-2017-state-of-online-retail-performance-report
Portent Site Speed Revenue Impact Study (2022): https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm
Google Think with Google Mobile Site Statistics: https://www.thinkwithgoogle.com/consumer-insights/consumer-trends/mobile-site-load-time-statistics/*

The technical differences that matter

Static generation vs server processing

Without caching, WordPress pages are dynamically created on the server. Every site visitor triggers PHP code to be generated, database calls, and server processing. Even with caching, this creates inherent delays.

SSG frameworks pre-build everything beforehand, so when someone visits the site, they're served pre-rendered HTML files, the same as the good old days when we created static HTML websites.

The mfyz.com case study shows WordPress delivered nearly 120KB of combined resources (HTML, CSS, JS) per page, whereas the Astro version delivered just 23KB, an 80% reduction in data transfer.

For mobile users on slower connections, this kind of difference determines whether a site loads in 2 seconds or 8 seconds. And this can make the difference between a page 1 organic ranking or a page 5 ranking in SEO terms.

SEO improvements

Basic static sites typically achieve near-perfect SEO scores in Lighthouse audits. WordPress sites average 86 points due to factors such as those listed here:

Render-blocking resources
Unused JavaScript bundles
Image optimization issues
Third-party plugin overhead

WordPress still makes sense

Don't get me wrong, I still believe WordPress is the best choice for specific scenarios and we continue to suggest it as our CMS of choice for those with heavy ongoing content management requirements or functional needs.

For example:

Complex editorial workflows: Multiple content editors, approval processes, user roles
E-commerce: WooCommerce provides extensive shopping functionality
Dynamic user content: Comments, user-generated content, membership sites
Non-technical teams: Familiar interface for content managers

However, most small business websites don't need these features. They need fast loading and good SEO.

The static site alternative

For small business websites, static generators offer several advantages, including:

Performance: Sub-second loading times
Security: No database to hack, minimal attack surface
Reliability: 99.9% uptime without server maintenance
Development time: Thanks to AI agents, development time can be much faster
Cost: Minimal hosting fees ($0-20/month on Netlify or Vercel vs $50-200/month on Litespeed for WordPress)

Popular options include:

Astro (my favourite): Best performance, supports multiple frameworks, great for SEO
Next.js: React-based with good SEO features
Gatsby: Rich plugin ecosystem, GraphQL integration
Hugo: Extremely fast build times, simple deployment

Should you migrate

Moving from a CMS platform like WordPress to a static generator requires planning:

Content migration: Most generators can import WordPress content via XML exports, API connections, or even markdown format.

Design rebuild: Themes need conversion to static templates, though many agencies now offer this service.

Content management: Consider headless CMS options like Contentful, Strapi, or Forestry for non-technical content editors.

SEO preservation: Proper redirects, URL structure planning, and meta tag preservation to prevent search ranking loss.

Final thoughts

The data doesn't lie. WordPress performance continues declining while static generators improve. For small businesses who need a website developed quickly, with fast loading, strong SEO, and lower maintenance costs, static sites provide clear advantages.

It's not a case of whether SSGs perform better - there's a wealth of public test data to prove that they do. The question is whether your business can afford to ignore this performance gap while competitors gain market and ranking advantages.

About me: 15+ years experience in web development and digital marketing, having worked with over 100 business websites across various platforms and frameworks in the UK. Check out my profile on dev.to for more articles 👇🏻 If you want to stay in touch, you can follow me here.

David@OpaceFollow

UK based web developer, open-source and AI enthusiast, and technology writer. Founder of https://opace.agency since 2008.

Why I Chose Astro over WordPress and Even Next.js or React for My New Business Venture, Web-Site.Design

David@Opace — Thu, 18 Sep 2025 12:42:43 +0000

This is why I chose Astro after 15+ years advocating for popular open-source platforms like WordPress, and my recent testing of other "modern" frameworks like Node.JS and React that were recommended to me.

Running a web design agency

My agency promotes PHP/MySQL based open-source CMS platforms like WordPress, Drupal and Joomla, and has done since being founded in 2008.

I’ve always been a massive fan of open-source, software re-use, not re-inventing the wheel, and critically, not locking customers into proprietary code or systems.

Using LLMs like ChatGPT

I've been writing about and experimenting with AI tools from before the days of ChatGPT, so when I decided to launch my newest venture, Web-Site.Design, I knew we needed to integrate AI to stand out in the market.

Since ChatGPT came out in 2022 and the subsequent LLMs that followed, like Claude and Gemini, everything has changed. From brainstorming ideas to fixing writer's block or debugging code, I have never looked back. Then, with each new GPT version, LLM provider or model, the capabilities and possibilities have got better and better.

Using LLMs to create websites

For a while now, we've been able to create basic websites using AI, but we're now at the point where complex apps and online solutions can be developed almost entirely by AI. I say "almost" as this still needs technical skill and human oversight to get it right.

Evaluating my options

After evaluating a wide range of frameworks and technologies, including React, Next.js, and other Node.js-driven stacks, I decided on Astro. Not only for our own site, but as the default framework for every customer site we now build.

Honestly, the decision was easy!

Why Not WordPress, Drupal or other PHP/SQL platforms?

WordPress and Drupal have served us (and countless businesses) incredibly well. They’re powerful, flexible, and benefit from massive plugin ecosystems. But they come with trade-offs:

Performance bottlenecks, especially without heavy optimisation.
Complex maintenance overhead - plugins, themes, security patches, updates, etc.
Bloated output when compared to modern-day expectations for mobile-first sites with lightning-fast load times.
Increased risks of hacks and vulnerabilities with each new plugin or extension installed.
Slower development times compared to other options and often expensive builds when complex or custom requirements are involved.

For Web-Site.Design, the promise is rapid, AI-powered, human-perfected custom builds, but at a price point that is too hard for any small business, startup or new venture to resist (£50/month), including research, design, content, hosting and deployment.

This needed to offer something different to our standard services at Opace, something that didn't suffer from the same trade-offs. I needed something faster, leaner, and easier to automate and version-control.

Why Not React, Next.js, or Node.js?

I love React and I’ve worked with Next.js. They’re great for developing certain use cases, especially internal tools or those with app-like experiences. But for small businesses, they need their websites to be found by customers and search engines like Google.

I still recall the first headless build we did at Opace, which used Next.js to create a headless front-end running on top of the WordPress CMS and various APIs which integrated into the client’s mobile app. It was fast and looked amazing until I clicked 'view source' and realised there was nothing there. With SEO being my main strength, I pushed back and said it wouldn't work. In hindsight, I would have done things very differently.

As well as the SEO issues, they introduce unnecessary complexity:

Overhead: Next.js/React often ship more JavaScript than necessary for content-heavy sites.
SEO challenges: While SSR and SSG solve some issues, they’re still not as good as clean HTML.
Development speed: Great for apps, but slower for rapid prototyping, especially when working with non-technical clients.

Our business model depends on rapid development using prompt engineering and AI agents, typically like Bolt.new for the initial ux.

We use ChatGPT or Manus in agent mode to do the research, planning and create the brief.

Then, to perfect the site, our developers use Claude Code or GPT-5 Codex running inside environments like VS Code with Roo Code to add the final touches, deploy, and iterate until complete.

Why Astro Was the Perfect Fit 🌟

Astro hit the sweet spot for us for a whole range of reasons:

✅ Open Source Philosophy
Astro is open source. This fits perfectly with our long-standing philosophy of being an open-source web development agency. Building upon our existing stack, including platforms like WordPress and Drupal, we can continue building on that ethos with Astro.

✅ Fast & SEO Friendly
Ships zero JavaScript by default. That means fast load speeds, amazing Core Web Vitals, and a near-perfect Lighthouse score out of the box. With my SEO and digital marketing background, this was non-negotiable. Search engine bots can fully crawl and index our sites with all code visible directly in the raw HTML source.

✅ AI-driven workflows
Ideal for AI-assisted web development. Because we use AI agents to scaffold, write, and refine code, Astro’s simplicity (with its file-based routing, Markdown/MDX support, and integrations ecosystem) means AI can generate usable, production-ready code far faster than how we normally work.

✅ Easy Version Control & Deployment
Everything gets deployed cleanly to GitHub. Deployment pipelines are straightforward. Whether pushing to Netlify, Vercel, or Cloudflare Pages, the workflow just works. For us, this means we can go from code to full website in under 7 days, sometimes less than 24 hours.

✅ Great Ecosystem & Integrations
We’re already standardising on excellent community tools like
Astro SEO for schema/meta tags and Astro Sitemap for automated sitemap generation.

We’re also building some of our own integrations, which we plan to publish on GitHub soon, including more advanced SEO tools and front-end editing capabilities.

The Future at Web-Site.Design
With an amazing offer built on top of Astro for maximum SEO performance and future-proofing, we believe we're on to something great here - a web dev process that can be 90% automated and can be infinitely scaled, without the traditional bottlenecks associated attached to web design and development.

The caveat here, of course, is that this process only lends itself to smaller business sites that fit a typical mould.

For larger builds, e-commerce and custom requirements, Astro paired with AI is still a great choice, but the £50/month, 7-day promise isn't really achievable; but who knows, one day maybe it will be.

We’ve gone from an agency rooted in traditional PHP/SQL platforms (via Opace.agency) to a forward-looking model that embraces AI, automation, and the next generation of web frameworks.

Astro wasn’t just a random choice. It was the only choice that balanced performance, SEO, developer experience, and scalability with our vision.

What do you think?
Drop your thoughts below — I’d love to hear your experiences or answer any questions!

About me: 15+ years experience in web development and digital marketing, having worked with over 100 business websites across various platforms and frameworks in the UK. Follow me on dev.to for more articles 👇🏻

David@OpaceFollow

UK based web developer, open-source and AI enthusiast, and technology writer. Founder of https://opace.agency since 2008.