A Decision-Useful XT-Commerce SEO Audit Checklist

Start with the runtime because application changes are hard to interpret when the server baseline is unknown. Capture the active PHP build, enabled extensions, cache behavior, database evidence, compression headers, error logs, and representative request timing before changing production.

Checkpoint: PHP runtime and OpCache compatibility. Evidence required: the active PHP version, required extensions, OpCache status, current errors, and a staging test covering the XT-Commerce storefront, administration, checkout, scheduled jobs, and connected services.

Pass condition: the tested stack is supported and stable on PHP 8.3 or higher, with consistent rendered output and no material functional regression in the tested flows. Fail condition: unsupported application code, extension conflicts, fatal errors, broken integrations, or template output that changes unexpectedly.

Severity: high when compatibility, security, or transaction flow is affected. Owner: XT-Commerce developer or server developer. Corrective action: stage the runtime change, repair confirmed incompatibilities, and tune OpCache from measured workload instead of copying generic values.

Earlier material in this source stated that higher versions reduce server response times by 15-25 percent. No supporting source URL is present in the source JSON, so this range should remain historical material requiring source reconciliation rather than a verified expectation.

Validation: repeat the same functional checks and compare server-side timing under equivalent conditions. Tools: Server Shell, New Relic

Checkpoint: object caching. Evidence required: repeated query or object access, cache hit behavior, invalidation events, memory use, and checks for price, stock, account, and checkout freshness when Redis or Memcached is used.

Pass condition: the cache removes confirmed redundant work without returning stale commerce data or creating inconsistent sessions. Fail condition: the cache has no defensible benefit, serves stale transactional data, or produces unstable application behavior.

Severity: medium to high based on affected templates and transaction paths. Owner: application developer or infrastructure developer. Corrective action: cache only suitable objects, define invalidation around the catalog and transaction lifecycle, and remove cache rules that cannot be kept correct.

Validation: compare equivalent product, category, account, and checkout requests before and after deployment and verify data freshness. Tools: Redis, XT-Commerce Cache Manager

Checkpoint: MySQL indexes and slow queries. Evidence required: slow-query evidence, query plans, table size, lock behavior, and the statements affecting products_description, orders, category navigation, search, and account operations.

Pass condition: priority storefront queries use appropriate access paths and avoid unnecessary full scans, repeated work, or blocking under representative load. Fail condition: recurring slow statements, avoidable scans, or index choices that materially delay a user-facing or transaction template.

Severity: high when storefront navigation, search, account functions, or checkout is affected. Owner: database developer or XT-Commerce developer. Corrective action: change indexes or queries only after reviewing execution plans, selectivity, write overhead, and the workload that triggers the delay.

Validation: run the same query set after the change and compare plans, execution behavior, and affected page response evidence. Tools: phpMyAdmin, MySQL Slow Query Log

Checkpoint: response compression. Evidence required: response headers, content types, transfer sizes, and rendering checks for representative HTML, CSS, and JS responses. Pass condition: Brotli or Gzip is applied to suitable responses without double compression, corrupted assets, or incompatible delivery.

Fail condition: compressible assets are transferred without compression where the server is expected to provide it, or compression introduces delivery or rendering defects. Severity: medium. Owner: infrastructure developer.

Corrective action: configure server-level compression only for appropriate MIME types and confirm that upstream or CDN behavior does not duplicate the work. Validation: recheck headers, transfer size, and rendered pages under the same test conditions. Tools: GTmetrix, Lighthouse

Build a URL-state map before changing redirects, canonicals, robots rules, or indexation directives. XT-Commerce installations can expose the same catalog intent through rewritten paths, parameters, pagination, filters, or legacy application URLs, so each state needs an observed purpose before consolidation.

Checkpoint: dynamic parameter handling. Evidence required: crawl samples for 'pID', 'cPath', session parameters, sort and filter parameters, the internal links that generate them, status behavior, canonical targets, and any indexed variants visible in available search data.

Pass condition: each useful catalog state has a stable preferred URL and internal navigation does not create unnecessary equivalent variants. Fail condition: substantially equivalent content is repeatedly exposed through competing parameter and rewritten URLs without a clear purpose.

Severity: critical when the pattern affects a large portion of the catalog or creates widespread indexation ambiguity. Owner: XT-Commerce developer with technical SEO review. Corrective action: configure SEO-URL behavior from the mapped pattern and use the existing XT-Commerce SEO mistakes guide for related parameter checks.

Validation: re-crawl the affected templates and compare generated URL states, canonical relationships, and indexable variants. Tools: Screaming Frog, XT-SEO Module

Checkpoint: self-referencing canonicals. Evidence required: rendered canonical tags across products, categories, pagination, tracking states, sort orders, and filtered pages, plus the response behavior of each target.

Pass condition: each canonical accurately represents equivalent content and resolves to the intended valid preferred URL. Fail condition: canonical targets are unrelated, blocked, redirected, inconsistent across equivalent pages, or detached from the URL model the store actually uses.

Severity: high. Owner: template developer or SEO developer. Corrective action: generate absolute canonicals from the intended URL model and define state-specific behavior rather than forcing one template rule across every catalog variation.

Validation: inspect rendered source, re-crawl canonical relationships, and spot-check target responses after deployment. Tools: Google Search Console, Sitebulb

Checkpoint: robots.txt access controls. Evidence required: the current robots.txt file, crawl paths into /admin/ and /checkout/, internal references to those paths, and confirmation that public pages or resources needed for rendering are not unintentionally blocked.

Pass condition: non-public areas are restricted as intended while useful public content and required resources remain accessible to supported crawlers. Fail condition: important pages or assets are blocked, or low-value or private paths are needlessly exposed to crawling.

Severity: high when rendering or indexation of useful public pages is affected. Owner: server owner or technical SEO owner. Corrective action: change rules only after confirming the purpose and crawl behavior of each affected path, without treating crawl-budget language as a substitute for evidence.

Validation: retest representative allowed and disallowed URLs and confirm crawler access behaves as designed. Tools: Robots.txt Tester

Checkpoint: discontinued-product responses. Evidence required: product availability, inbound links, internal links, replacement products, category relevance, current response behavior, and whether the unavailable page still helps a shopper.

Pass condition: removed or unavailable products use the response that best reflects their real state, and only genuine permanent replacements are redirected with a 301 response. Fail condition: arbitrary redirects, broken internal links, irrelevant destination mapping, redirect chains, or an unhelpful 404 response where a maintained unavailable page would still serve a valid user need.

Severity: medium to high depending on catalog scale, link value, and user impact. Owner: merchandising owner with developer support. Corrective action: redirect only to a relevant permanent replacement; otherwise maintain a useful unavailable page when appropriate or return the appropriate not-found response.

Validation: test destination relevance, response behavior, internal links, and crawl status after the change. Tools: Redirection Plugin, Ahrefs

Treat structured data as a consistency layer for facts the store can support. Earlier wording in this source described 2026 SEO as requiring entity definition through JSON-LD. Keep that as historical editorial context only.

Current implementation decisions should instead be based on documented eligibility requirements, accurate visible content, and whether the markup describes the page without inventing evidence or implying guaranteed rankings or Knowledge Graph treatment.

Checkpoint: Product structured data. Evidence required: rendered product markup, visible price and availability, product identifiers where present, and review information only where it was legitimately collected and displayed under the applicable rules.

Pass condition: eligible Product data is accurate, internally consistent, and aligned with the page content and catalog source. Fail condition: fabricated review values, stale price or availability, conflicting fields, unsupported properties, or markup that describes something other than the visible product.

Severity: high. Owner: template developer with merchandising review. Corrective action: populate markup from authoritative catalog fields, remove unsupported values, and repair the data flow that caused the mismatch.

Validation: test representative products with the relevant validation tools and compare parsed values with the visible page and source catalog. Tools: Schema Pro, Google Rich Results Test

Checkpoint: Organization structured data. Evidence required: the business name used publicly, brand identity shown on the site, contact information, and any candidate SameAs destinations. Pass condition: Organization data describes the actual business represented by the site, and SameAs references, when used, point to profiles for that same entity.

Fail condition: inconsistent names, made-up profiles, unrelated destinations, or references included only to imply authority. Severity: medium. Owner: site owner with developer support. Corrective action: normalize business fields around one defensible source of truth and include only references that can be verified as belonging to the organization.

Validation: inspect the rendered JSON-LD and compare it with the public business information presented on the site. Tools: JSON-LD Generator

Checkpoint: BreadcrumbList data. Evidence required: visible breadcrumb navigation, category hierarchy, product placement, and the corresponding structured-data trail on representative sub-pages. Pass condition: structured breadcrumbs mirror the navigational path a user can see and use valid destination URLs.

Fail condition: missing hierarchy levels, mismatched labels, invalid destinations, or machine-readable breadcrumbs that conflict with the visible navigation. Severity: medium. Owner: template developer.

Corrective action: generate BreadcrumbList output from the same hierarchy used to render the visible breadcrumb instead of maintaining a separate hard-coded trail. Validation: crawl representative category and product paths and compare visible labels, hierarchy, and parsed URLs. Tools: Structured Data Validator

Checkpoint: merchant shipping and return information. Evidence required: the current published shipping and return policies, Merchant Center configuration where used, catalog or feed settings, and any policy data emitted by Custom XT-Hooks.

Pass condition: machine-readable policy information, when implemented, agrees with the actual terms shoppers can read and the data sent through connected merchant systems. Fail condition: conflicting, incomplete, stale, or misleading shipping or return details.

Severity: high when the discrepancy could mislead a shopper or create policy inconsistency. Owner: operations or compliance owner with developer support. Corrective action: maintain one authoritative policy source and update templates, feeds, and integrations from that source.

Validation: compare the website, merchant configuration, feed output, and rendered structured data after the correction. Tools: Merchant Center, Custom XT-Hooks

Use template checks to determine whether category and product pages communicate their purpose clearly to shoppers and search systems without turning house style into an undocumented ranking rule.

Checkpoint: heading hierarchy. Evidence required: rendered H1 through H3 elements across representative category templates, the visible page title, reusable modules, and the visual purpose of each heading.

Pass condition: the H1 identifies the main page topic within a coherent document hierarchy and heading levels are not assigned merely to obtain a visual style. Fail condition: semantic headings are used as decoration, the principal topic is unclear, or repeated H1 elements come from unrelated template modules without a defensible document purpose.

Severity: medium. Owner: front-end developer or template developer. Corrective action: separate CSS presentation from semantic heading choices and apply the single-primary-heading convention only as a maintainable template rule, not as an unsupported universal ranking requirement.

Validation: inspect rendered markup across representative categories after the template change. Tools: ContentKing, SurferSEO

Checkpoint: product image filenames and alt text. Evidence required: representative product images, current filenames, rendered alt attributes, image purpose, and surrounding product context. Pass condition: informative images have alt text that communicates their relevant content for accessibility, decorative images use appropriate empty alt treatment, and filenames are maintainable where renaming is practical.

Fail condition: meaningful images lack useful text alternatives, alt text is stuffed with search phrases, or generated text misdescribes the image. Severity: medium. Owner: merchandising owner or content operations owner.

Corrective action: replace opaque names such as 'DSC001.jpg' with descriptive file naming when operationally safe, for example 'leather-briefcase-brown.jpg', and write alt text for the user and image purpose rather than keyword density.

Validation: sample rendered product pages, inspect the final attributes, and verify expected accessibility behavior. Tools: Bulk Image Resizer

Checkpoint: category descriptions. Evidence required: category intent, actual inventory, existing copy, subcategory relationships, internal links, and buyer questions that can be answered from the catalog.

Pass condition: an important category contains enough original, accurate information to explain the range, distinguish relevant choices, and help a shopper navigate to suitable products or subcategories.

Fail condition: copied manufacturer language, empty boilerplate, unsupported claims, or copy added only to satisfy an arbitrary length target. Severity: medium to high for strategically important categories.

Owner: merchandising owner or content owner. Corrective action: if 300-500 words are genuinely useful for the category, use that space to answer relevant buyer questions, explain selection criteria supported by the inventory, and connect users to appropriate products or subcategories.

For broader platform support, use the <a href="/industry/ecommerce/xt-commerce">XT-Commerce SEO hub</a>. Validation: compare the finished page with live inventory and intended search demand, then confirm that its internal links, text, and product relationships render correctly. Tools: Frase, MarketMuse

Checkpoint: WebP image conversion for product thumbnails - High - 2 hours. Evidence required: current thumbnail formats, browser support requirements, source quality, rendered dimensions, and transfer sizes.

Pass condition: converted thumbnails load correctly where supported, remain visually acceptable, and reduce unnecessary payload for the tested assets. Fail condition: conversion breaks delivery, creates visibly degraded product imagery, increases transfer cost, or lacks a safe fallback where one is required.

Severity: high when image delivery materially affects many catalog pages. Owner: front-end developer. Corrective action: enable conversion only for suitable assets and delivery paths, with safe fallbacks where required by the supported environment.

Validation: compare requests, file sizes, and rendered output on representative product and category templates before and after deployment.

Checkpoint: broken internal links from the latest crawl - Medium - 3 hours. Evidence required: a fresh crawl showing each source page, intended destination, response behavior, and link context. Pass condition: intentional internal links resolve directly to a useful destination that matches the surrounding context.

Fail condition: a link resolves to a broken, irrelevant, or avoidably redirected destination. Severity: medium unless the affected link blocks an important shopping or crawl path. Owner: content owner or technical SEO owner.

Corrective action: repair, replace, or remove the link according to the intended destination and current catalog state. Validation: re-crawl the repaired URL set and confirm both destination behavior and source-page markup.

Checkpoint: footer copyright year - Low - 10 minutes. Evidence required: the rendered footer, template source, and the site's chosen copyright presentation. Pass condition: the displayed year is accurate for that presentation and appears consistently where the shared footer is expected.

Fail condition: the footer shows stale or inconsistent information caused by a template defect. Severity: low. Owner: front-end owner or content owner. Corrective action: update the shared template or data source if the displayed year is incorrect.

Validation: confirm the footer on representative templates after deployment. Treat this as content maintenance, not as an official ranking factor.

• Default index.php paths. Evidence required: crawl and internal-link reports showing whether default application paths compete with rewritten URLs for the same catalog content. Pass condition: one intended URL pattern is used consistently for each equivalent state. Fail condition: equivalent pages remain reachable and indexable under competing default and rewritten paths without a deliberate need. Severity: high when duplicate equivalents are broadly exposed. Owner: XT-Commerce developer. Corrective action: consolidate only confirmed duplicates and update the links or routing rules that keep generating the unwanted state. Validation: re-crawl responses, canonicals, redirects, and internal links and confirm the intended pattern is now dominant.
• Mobile checkout usability. Evidence required: supported-device testing, form-field behavior, validation errors, viewport rendering, layout shifts, keyboard behavior, and the steps required to complete checkout. Pass condition: a customer can reliably complete every required checkout interaction on supported mobile viewports. Fail condition: rendering or interaction defects block, obscure, or materially interfere with required steps. Severity: critical when purchase completion is blocked. Owner: front-end developer and commerce developer. Corrective action: repair the observed interaction, validation, or layout defect without changing unrelated checkout behavior. Validation: repeat an end-to-end mobile checkout test using the same affected path and confirm the defect no longer occurs.
• Manufacturer-provided product copy. Evidence required: the store's product text, supplier feeds, actual product attributes, and comparison with other retailers where that comparison is available to the team. Pass condition: important products contain accurate merchant-specific information wherever the store can add useful selection, fit, compatibility, care, or purchasing context. Fail condition: duplicated supplier copy leaves material buyer questions unanswered or introduces wording that does not match the actual item. Severity: medium. Owner: merchandising owner or content owner. Corrective action: improve only the pages where accurate original information will help a shopper evaluate the product, and keep factual claims tied to the catalog or verified product documentation. Validation: review a sample after publication and confirm that the copy matches the actual product data and rendered page.
• Security patches. Evidence required: installed XT-Commerce version, extension inventory, vendor advisories available to the team, deployment records, and relevant server logs. Pass condition: applicable security updates are assessed, tested, and deployed through a controlled change process, or a documented mitigation exists for a confirmed constraint. Fail condition: a known relevant vulnerability remains exposed without an accepted mitigation or remediation path. Severity: critical when the installation is exposed. Owner: security owner or platform developer. Corrective action: patch or mitigate the affected component, test the storefront and transaction paths, and monitor for regressions. Validation: confirm the deployed component state and affected behavior after the change. Keep security status framed as risk management rather than as an undocumented ranking factor.