01CMS
WordPress
Plugin and theme updates, thin archive and attachment pages, permalink changes and host migrations.
Open the WordPress hubPlatforms
CMS SEO Auditsby Platform
Every content management system breaks SEO in its own way. WordPress plugins rewrite canonicals, Wix and Shopify fix some URL patterns in place, Webflow publishes a staging copy of the site, and Magento's layered navigation can multiply one category into thousands of URLs.
Knowing the platform before you crawl tells you where to look. This hub shows how to identify a site's CMS, what each platform lets you control, and how to validate every change with a before and after crawl.
Technical audit focus. Platform guides cover the settings, templates and URL patterns behind each issue, not generic SEO tips.
Which platform is the site on?
5 platforms
01
WordPressPlugins, themes, archives, permalinks
02
WebflowPublishes, CMS collections, staging domain
03
WixURL prefixes, dynamic pages, redesigns
04
MagentoFaceted navigation, duplicates, deployments
05
ShopifyTheme updates, duplicate product URLs, redirects
Baseline, change, crawl, compareEvery platform guide uses the same loop, so audits stay comparable across sites and releases.
Why it matters
Why the CMS changes the audit
A CMS decides three things that shape every technical SEO audit: which signals you can control, which pages it generates on its own, and how changes reach the live site.
Control varies widely. On WordPress or Magento you can edit almost any tag, URL or rule. On hosted builders, some URL prefixes, canonical behavior and sitemap logic are set by the platform. Generated pages vary too: tag archives, collection items, filter combinations, product paths and staging copies all appear without anyone writing them.
Release paths differ most. A plugin update, a Publish button, a theme switch and a code deployment each push different kinds of change. The audit has to follow the way the platform ships.
Two different jobs
Built-in checks are not a site audit
- Built-in CMS checksSEO plugins, page audit panels and setup checklists review one page or one setting at a time, inside the editor. Useful while writing.
- Crawl-based auditsA crawler fetches every URL the way a search engine does, so it finds template defects, URL pattern explosions and site-wide settings that one-page checks never see, and it can compare today's output with last week's.
Detection
How to identify a site's CMS and tech stack
Check before you scope or price an audit. Most platforms leave signatures in the page source, asset paths or default URLs. Tools like Wappalyzer and BuiltWith give a quick answer for one URL. A crawl with Custom Source Search confirms the signature across every page, which matters when one section of a site runs on a different system.
| Platform | Look for in the source | Other clues |
|---|---|---|
| WordPress | /wp-content/, /wp-includes/, /wp-json/ | Generator meta tag, /wp-login.php, plugin comments in the head |
| Shopify | cdn.shopify.com, /cdn/shop/, Shopify.theme | /products/, /collections/ and /pages/ URL prefixes |
| Wix | static.wixstatic.com, parastorage.com | Generator meta tag, /post/ and /product-page/ prefixes |
| Webflow | data-wf-page, data-wf-site, website-files.com | Generator meta tag, a matching webflow.io subdomain |
| Squarespace | static1.squarespace.com, Static.SQUARESPACE_CONTEXT | /blog/ collection URLs, /s/ file paths |
| Magento | /static/version, /frontend/, form_key, Magento_ modules | .html product URLs, ?product_list_order parameters |
| Drupal | /sites/default/files/, drupal-settings-json | Generator meta tag, /node/ paths, /user/login |
| Joomla | /media/jui/, /components/com_ | Generator meta tag, /administrator/ |
| Next.js or Nuxt frontend | /_next/, __NEXT_DATA__, /_nuxt/, __NUXT__ | Usually a headless setup with content from a separate CMS |
Security-conscious sites remove generator tags and move admin URLs, so rely on asset paths and URL patterns rather than one clue.
Reference
What each platform lets you control
The same SEO signal is controlled in very different places across platforms. Use this table to set expectations before the audit and to know where each fix will happen.
| Platform | robots.txt | Canonical tags | Redirects | URL structure | XML sitemap | Main generated risk |
|---|---|---|---|---|---|---|
| WordPress | Editable file or plugin | Core on posts and pages, full control through SEO plugins | Plugin or server rules | Flexible permalinks | Core or plugin generated | Thin archives, plugin conflicts, staging noindex |
| Webflow | Editable in site settings | Global canonical setting, page overrides | Built in, wildcard rules | Collection URL plus item slug | Automatic or custom | Indexable webflow.io copy, unbound template fields |
| Wix | Editable in SEO settings | Automatic self canonical, overrides per page or page type | Built in redirect manager | App prefixes such as /post/ | Automatic index per page type | Thin dynamic pages, settings left behind in redesigns |
| Magento | Editable in admin | Configuration toggles for products and categories | URL rewrites | Flexible keys, suffix and category paths | Generated on a schedule | Layered navigation URLs, duplicate product paths |
| Shopify | Editable through a theme template | Automatic, theme controlled | Built in | Fixed prefixes such as /products/ | Automatic | Collection product paths, tag filter URLs |
| SquarespaceGuide soon | Platform managed | Automatic | Built in URL mappings | Partly fixed collection paths | Automatic | Tag and category listings, limited schema |
| DrupalGuide soon | Editable file | Core plus metatag modules | Redirect module | Path aliases, often pattern based | Module generated | Raw /node/ paths alongside aliases, taxonomy pages |
| HeadlessGuide soon | Built in the frontend | Built in the frontend | Frontend, CDN or host | Whatever the routes define | Built in the frontend | Missing metadata, sitemaps out of sync, client-side rendering |
Platforms change their settings often. Treat the table as a starting point and confirm the current behavior with a crawl.
Platform guides
Platform SEO audit guides
Each hub covers what to check on that platform, the audit workflow, common findings and focused guides for the changes that break SEO most often there.
02Site builder
Webflow
Checks after every publish, CMS collection templates and field bindings, and migrations into Webflow.
Open the Webflow hub03Site builder
Wix
Redesigns built as new sites, dynamic item pages, SEO patterns and migrations to or from Wix.
Open the Wix hub04Ecommerce
Magento Open Source
Layered navigation URLs, duplicate product paths, canonical behavior and checks after each deployment.
Open the Magento hub05Ecommerce
Shopify
Theme update regressions, duplicate product URLs through collections, URL redirects and migrations into Shopify.
Open the Shopify hub06Site builder
SquarespaceSoon
Collection URLs, tag and category listings, URL mappings and template version changes.
07CMS
DrupalSoon
Path aliases and raw node URLs, taxonomy term pages, module updates and multilingual setups.
08Architecture
Headless CMSSoon
Rendering mode, frontend-built metadata, sitemap sync and routes that expose duplicate paths.
Workflow
The audit loop every platform shares
The settings differ by platform. The method does not. These six steps work on any CMS and keep results comparable from one change to the next.
Identify the platform and how it ships changes
Plugin updates, publishes, theme switches and code deployments each need a different checkpoint.
Save a baseline crawl before the change
Use the same crawl settings and scope every time, especially on large catalogs with filter parameters.
Check one URL from every page type
Posts, pages, archives, collection items, products, categories and filtered listings each come from their own template.
Group findings by template, URL pattern and setting
A defect on every URL in one folder is one fix on one template, not hundreds of page edits.
Fix the cause where the platform controls it
Plugin, theme, collection template, SEO pattern, admin setting or code. The matrix above shows where.
Crawl again and compare against the baseline
Every difference should be one you planned. Anything else is a regression. See Audit Comparison.
Architecture
Headless and JavaScript-heavy sites
A headless setup keeps content in one system, such as Contentful, Sanity or a headless commerce backend, and builds the frontend separately, usually with Next.js, Nuxt or another framework. Nothing a traditional CMS outputs automatically exists unless the frontend builds it.
Start with rendering. Server-side rendering and static generation deliver complete HTML. Client-side rendering builds the page in the browser, so crawlers that do not run JavaScript see an empty shell. Crawl with JavaScript Rendering on and compare raw and rendered output.
Then check every page type, not just the homepage, for its own title, description, canonical, robots tag and schema. JavaScript SEO covers the rendering details.
What goes wrong most
Headless audit checks
- RenderingLinks and body text missing from the raw HTML on client-rendered routes.
- MetadataDefault titles and missing canonicals on templates the frontend team never configured.
- SitemapsStatic sitemaps that fall out of sync with published content.
- Duplicate routesThe same content reachable through several paths with no canonical.
Diagnosis
Diagnosing a drop after a platform or tech change
When traffic falls and nothing obvious is wrong, the cause is often a change in the technology behind the site: a new theme, a replatform, a rendering switch or an extension update. Clients rarely remember the details, and the old site is gone.
Saved crawl history answers the question directly. Compare the last crawl before the drop with the first one after it, filter by template and URL pattern, and the change that moved titles, canonicals, indexability or internal links stands out.
That only works if the baseline exists. Scheduled SEO Audits keep one for you, so the comparison is ready when you need it.
| Signal | What a shift points to |
|---|---|
| Indexable URL count | New generated pages, or a noindex setting carried over |
| Status codes on old URLs | Missing redirects after a URL structure change |
| Titles and descriptions | Template defaults replacing page-level SEO |
| Canonical targets | A new plugin, app or extension owning the tag |
| Raw vs rendered links | A switch to client-side rendering |
| Word count per template | Content moved into images, tabs or scripts |
Implementation
Who fixes what on each platform
An audit is only useful once the fixes ship. Naming where each fix lives, and who owns it, turns findings into tickets that get done.
Page and item content
Titles, descriptions, headings and alt text on single pages, posts, CMS items and products.
Platforms: all, through page settings or SEO fields.
Settings and patterns
Indexing toggles, SEO patterns, redirect managers, robots.txt and sitemap options.
Platforms: Wix, Webflow, Shopify, Squarespace, plugin settings on WordPress.
Templates
Heading levels, field bindings, collection and dynamic page layouts, and which content sits in the HTML.
Platforms: Webflow, Wix, WordPress themes, Shopify themes.
Code and configuration
Layered navigation rules, canonical logic, rendering mode, server redirects and release processes.
Platforms: Magento, Drupal, custom WordPress, headless frontends.
Know the platform, then measure the output
The CMS tells you where problems are likely to start. A crawl tells you whether they did. SiteAuditLint crawls any platform from your own computer, renders JavaScript when needed, and keeps audit history so every change can be compared with the last.
Free version audits up to 100 URLs per crawl. Pro adds audit history and comparison.
FAQ
CMS SEO audit questions
Does the CMS affect SEO rankings?
Not directly. Search engines rank pages, not platforms. The CMS decides what you can control, such as URL structure, canonical tags, robots.txt, redirects and rendering, and what it generates without asking, such as archives, filter URLs and duplicate product paths. Those decisions shape what crawlers find.
Which CMS is best for SEO?
The one your team can control and validate. WordPress, Magento and Drupal offer the most control and the most ways to break things. Shopify, Wix, Squarespace and Webflow handle hosting and sitemaps for you but fix some URL patterns in place. A well-audited site on any of them beats a neglected site on the most flexible one.
How do I find out what CMS a website uses?
Check the page source for a generator meta tag and platform asset paths, such as /wp-content/ for WordPress, cdn.shopify.com for Shopify or /_next/ for Next.js. A crawl with a source search can confirm the signature across every page, and tools like Wappalyzer or BuiltWith give a quick answer for one URL.
Is a CMS's built-in SEO checker enough?
Built-in checkers review one page or one setting at a time. Most CMS SEO problems come from templates, URL patterns and site-wide settings, which only show up when you crawl every page and compare results over time.
Can you audit a headless CMS site?
Yes, but check rendering first. Compare the raw HTML with the rendered HTML, then confirm every page type has its own title, description, canonical and schema, because a headless frontend has to build all of them itself.
When should a CMS site be audited?
Before and after every change that can alter output at scale: plugin or extension updates, theme changes, publishes, deployments, redesigns and migrations. Between changes, a scheduled crawl catches drift.
Change guides
Audit after a change
- WordPress plugin or theme updatesRegression checks after code updates
- Webflow publishesSlugs, template fields, staging domain
- Wix redesignsPage SEO and redirects in a new site
- Magento deploymentsConfig, extensions and cache
- Shopify theme updatesRegression checks after a theme change
- Shopify URL redirectsHandle changes, deleted products, 404s
Migrations
Move platforms safely
In SiteAuditLint
Run the audit
Crawl any CMS, group issues by template, and compare each crawl with the last one.