Changelog

What each release means for your store. Every entry is written in terms of what you can do afterwards that you could not do before, and what changed about behaviour you may have been relying on.

1.4.0 — 3 October 2026

One addition and a set of fixes. The addition is that an update now keeps what you set, which takes one new table, oc_seo_setting, created at install and kept at uninstall like the other three. No setting is added and none changes meaning, and SEO Suite Pro still has no API.

An update gives your settings back. Until now every update reset every template, wording, sitemap cycle, redirect cap and return policy you had typed, on the default shop, while your other shops kept their settings, switches included, and came back partly on. SEO Suite Pro now keeps its own copy of what you save on each of the five screens, per shop, and puts it back when the new version installs. The switches are the exception: the suite and each of the five areas come back off on every shop, the way a fresh install arrives, so after an update you switch on what you had running and nothing else needs typing again. Detailed logging comes back off too.

This update is the one that cannot keep them. It is 1.3.0's uninstall that runs at the start of the update, before 1.4.0's copy exists, so updating to 1.4.0 still asks for every value again. Note your settings down, or take a screenshot of each screen, before you update. Every update after this one keeps them. Limits has the detail.

Remove everything held about a person no longer takes your redirects. The button on that screen under Customers emptied the whole redirects table: every redirect rule you had written and the Broken URLs list with it, behind a screen saying your configuration was untouched. It now blanks the one column that can carry a person, the address a broken URL was reached from (Linked from), and keeps every path and every rule.

A sitemap that could not be written in full is no longer published. On a full disk or a hosting quota a run used to put a cut-off sitemap in place of the old one and report it as generated. Now nothing new is published, crawlers keep the previous sitemap, and the screen says the disk refused the write. A robots.txt that could not be updated to point at the sitemap is reported the same way, rather than passed over.

The smaller fixes:

• A button that gets no answer says so. Preview and Generate on URLs & meta, Generate and Reset on Alt text, Generate sitemap, the CSV imports on Alt text, Markup and Redirects, and the two data-protection screens under Customers used to do nothing visible when the store did not reply, because a session had run out or the server timed out. Each now tells you what may or may not have happened and what to do next.
• An overrides import past the row limit says what it saved. It used to answer with an error only, after the rows above the limit had already been saved. It now names how many were.
• Every CSV download needs only access to its screen. The Alt text, Redirects and Markup overrides exports asked for modify, while the Broken URLs download asked for access. A download is a read, so all four now need access, and a user who can open the screen can download its file.
• An & or a quote stays as you typed it. Crawl rules on XML sitemap and descriptions written in the Alt text editor gained a layer of encoding each time you saved, so & became &. They are stored as typed now; one that already picked up & keeps it until you correct it and save once. The Alt text editor's product box also showed a product name with & in it as &, and the wording panel's language picker, on a store with more than one language, opened the login page instead of that language.
• A sitemap file name has to be a file name. File names begin with and Index file name take letters, numbers, dots, dashes and underscores, and the index must end in .xml. Anything else is not saved, and the shipped sitemap or sitemap.xml is used instead, so no name can overwrite a file of your store's own in the web root.
• A scheduled cycle is measured from the last run's start, the way OpenCart's own scheduler measures it, so the two agree on when a week or a month has come round, including across a change of the clocks.
• Installing grants the data-protection screens once. Each install or update added five more copies of those two permissions to your user group.
• Product cards cost less on OpenCart 4.0.2.x. On those releases the alt text checks ran again for every product card on a page; they now run once per page, as they already did on 4.1.
• The sitemap screen's help names Extensions → Cron Jobs, where OpenCart keeps its scheduler, rather than Marketplace.

1.3.0 — 30 September 2026

Three additions, each switched off until you turn it on, so an update changes nothing your store does. None of them adds a table or needs an outside service.

Product codes, every photograph and a return policy in the markup. On Markup, Product codes and photographs adds a product's GTIN, ISBN and MPN to its Product block, read from the codes you fill in on the product form, and lists every photograph the page shows rather than only the first. A GTIN whose check digit does not add up is left out rather than emitted. A new Return policy fieldset states one return policy for the whole shop, on the home page's Organization block: the kind of window, how many days, the countries it applies in, who pays for return shipping and how an item comes back. It says exactly what you typed and is checked against nothing, and until everything it needs is there the fieldset names what is missing. No shipping rate and no item condition are claimed, and limits says why.

Product photographs in the XML sitemap. On XML sitemap, Each product's photographs lists every image of a product under its URL, main image first, for image search. Only files that exist in your image directory are listed, each as the file you uploaded rather than a resized copy, and categories and manufacturers list none. The photographs count toward the size at which the sitemap splits, so a large catalogue may publish more files.

Every broken URL as a CSV. On Redirects, Download CSV under the Broken URLs list writes every URL still on it, for every store, most-hit first, where the screen shows only the twenty most-hit. Its first four columns are the import's own: fill in a target and a response for the rows you want to fix, delete the rest, and import the file back, as the guide walks through. Anyone who can open the Redirects screen can download it, and it carries the referrer each URL was reached from.

An update clears the new settings like every other one. The return policy in particular is not stated again until you retype it. The list under What an update keeps has each setting.

1.2.1 — 29 September 2026

Preview, Generate, Regenerate everything and Generate sitemap work again. In 1.2.0 those four buttons sent their request without your admin session's token, on every OpenCart release, so OpenCart answered as though you were not logged in and nothing was previewed, written or generated. The token now goes with every request, so URLs & meta previews a pattern and writes keywords for everything that has none, Regenerate everything rewrites them all after you confirm, and XML sitemap builds the sitemap in batches from the button again. Nothing you configured changes, and keywords and sitemaps written before this release are untouched.

Three smaller things ride along. Broken URLs on Redirects now says how many addresses it is actually showing, where it used to say twenty when it listed fewer. Placing SEO Suite Pro in a position under Design → Layouts, which OpenCart offers for every module, now draws nothing there, where it used to print an error and a stack trace into the storefront page. And the personal-data screen names one more defect in OpenCart's own erasure: on 4.1.0.0 to 4.1.0.3 a removal the cron carries out deletes the account and leaves everything attached to it behind.

1.2.0 — 21 September 2026

Adding a second language to a store on OpenCart 4.1.0.0 no longer fails. On that release the column OpenCart keeps a keyword's sort order in has no default, so a keyword SEO Suite Pro wrote left it empty. OpenCart's own add a language routine, which copies every keyword into the language it is adding, then handed that empty value to a function that refuses one. The save failed with a type error and no language was added. Keywords are now written with that sort order set to the same value OpenCart's own screens write, so the copy succeeds. Nothing changes for a store on any other release, and nothing changes about the keywords themselves.

4.1.0.0 is now a tested release. 4.1.0.1 and 4.1.0.2 are not, and limits says why: on those two, OpenCart refuses every new language outright, whatever is installed. The Markup screen now says so on a store that is on one of them.

1.1.0

The extension is now called SEO Suite Pro, on every screen it has. No behaviour changed, no setting moved, no table was touched, and nothing you configured needs revisiting.

4.0.2.1, 4.0.2.2 and 4.0.2.3 are now tested releases, alongside the three 1.0.0 was tested on.

It is a correction rather than a rebrand. The marketplace listing has read SEO Suite Pro since the day it was created, while the archive installed something called SEO Suite, so a buyer bought one name and found another in Extensions → Extensions → Modules. The manifest, the admin screens and the documentation now read what the listing always did.

The extension code is unchanged and stays seo, so this installs over 1.0.0 the way any update does.

1.0.0

The first public release. This is a baseline rather than a diff: nothing shipped before it, so everything below is what you get.

SEO Suite Pro is one extension doing five jobs, each on a screen of its own that you turn on independently. Uploading one archive and pressing Install once gets you all five; turning one on commits you to nothing about the other four.

URLs & meta generates URL keywords for products, categories and manufacturers, and meta titles and descriptions for products and categories, from a template per type per output, previewed against a real entity of that type before anything is written. Generate writes only where there is nothing; a second button, behind a confirmation, regenerates over the top of what is there. A run goes in batches and picks up where it stopped. It can also keep paginated, sorted and filtered listing pages canonical, which is off until you ask for it.

Markup emits the Open Graph and Twitter Card tags that make a pasted link unfurl as the thing it points at, and the JSON-LD that lets a search result show a price, an availability, a star rating and a breadcrumb trail. Six families switch independently. Every value is read from what the page itself computed, so the tag and the page cannot disagree about what a shopper would pay, and a star rating is claimed only where the product has approved reviews. You can override one page's canonical, or take it out of search results, without touching the rest.

Alt text describes every image of a product in its own words, per language, reaching the product page and every product card in the store. Write the photographs that matter under the picture on OpenCart's own product form; write one pattern and generate for the rest of the catalogue. Words somebody typed are never overwritten, descriptions export and import as CSV, and a theme whose image markup cannot be read is left exactly alone with the screen saying so.

Redirects records every request for a URL your store cannot resolve, with a hit count, when it was last seen and where it was linked from, and lets you give any of them a 301, a 302 or a 410. Chains are flattened when you save and loops are refused, so the storefront's answer is always one hop. Rules import and export as CSV, which is how a migration's worth of links is brought over from another platform. Slug renames made in the admin can be captured automatically; that is off by default, because a weekend of reorganising would otherwise collect a redirect for every slug you touched.

XML sitemap publishes a sitemap of everything each of your shops displays, split across several files with an index over them when a catalogue outgrows what a crawler will accept, and swept clean of anything a shrunken catalogue left behind. Your crawl rules are edited from the admin, into the block this extension owns in robots.txt. Every other byte in that file is left identically as it was, including the rules core ships and the ones you added by hand. It regenerates on a cycle you choose, driven by OpenCart's own scheduler, and from a command line for the release where that scheduler is broken.

What the suite holds about a person is published, and it is one column: the referrer a broken URL was reached from. No IP address, no customer, no session, no user agent. Customers → Personal Data answers what this and every other Kyvero extension on your store holds about one named person, and Customers → Remove everything held about a person removes it (in full).

What it wrote for you survives an uninstall. URL keywords, meta text, image descriptions, redirect rules, page overrides and crawl rules all stay, because an OpenCart upgrade is an uninstall followed by an install and losing your work for pressing Upgrade is not a trade anybody agreed to. The sitemaps are the one thing removed, because nobody can regenerate them once the extension is gone.

It runs on OpenCart 4.0.2.0 and newer, and a smoke pass has been through 4.0.2.0, 4.1.0.3 and 4.1.0.4 install-to-uninstall. On 4.1.0.4 OpenCart's own scheduler is broken inside OpenCart itself, which costs every extension on such a store its scheduled work; the screen names the release, says what it has cost you, and the command line door regenerates on whatever timing a crontab line gives it. Requirements.

Four controls of the security baseline are not met, and which four is published on that page rather than summarised here.

What an update keeps

Your settings come back, with the exceptions below. An update is an uninstall and then an install, and OpenCart deletes an extension's settings at the uninstall step. SEO Suite Pro keeps its own copy of them and puts them back afterwards. Each store keeps its own, apart from module_seo_status, module_seo_basics_product_keyword, module_seo_basics_product_meta_title, module_seo_basics_product_meta_description, module_seo_basics_category_keyword, module_seo_basics_category_meta_title, module_seo_basics_category_meta_description, module_seo_basics_manufacturer_keyword, module_seo_basics_path_separator, module_seo_basics_batch, module_seo_basics_diary_verbose_until, module_seo_markup_diary_verbose_until, module_seo_alt_text_copy, module_seo_alt_text_batch, module_seo_alt_text_diary_verbose_until, module_seo_redirects_capture, module_seo_redirects_cap, module_seo_redirects_diary_verbose_until, module_seo_xml_sitemap_status, module_seo_xml_sitemap_cycle, seo_xml_sitemap_rules, module_seo_xml_sitemap_prefix, module_seo_xml_sitemap_index and module_seo_xml_sitemap_diary_verbose_until, which SEO Suite Pro reads once for the whole installation.

These are asked for again rather than put back:

• module_seo_status — The suite comes back switched off after an update, the way a fresh install does — and so does each of the five areas, on every shop. Everything else you set on the five screens comes back as you left it, out of the suite's own copy, so turning the areas back on is the whole of it. What an update never touches is what the areas accumulated: your redirect rules, your image descriptions, your page overrides and your crawl rules.
• module_seo_basics_status — The module comes back switched off after an update, the way a fresh install does. Keywords and meta text a run has already written are untouched — they are catalogue rows rather than settings.
• module_seo_basics_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.
• module_seo_markup_status — The module comes back switched off after an update, the way a fresh install does. Your per-page overrides are untouched — they are rows rather than settings.
• module_seo_markup_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.
• module_seo_alt_text_status — The module comes back switched off after an update, the way a fresh install does. The descriptions you have generated are untouched — they are rows rather than settings.
• module_seo_alt_text_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.
• module_seo_redirects_status — The module comes back switched off after an update, the way a fresh install does. Your rules are untouched — they are rows rather than settings.
• module_seo_redirects_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.
• module_seo_xml_sitemap_status — The module comes back switched off after an update, the way a fresh install does. Your crawl rules are kept — they are the one thing here that survives.
• module_seo_xml_sitemap_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.

A setting a release adds does not change what your store does. Its default is what SEO Suite Pro did before the setting existed, so an update never asks you to go and set something to get back the behaviour you already had.

What this cannot tell you is whether a release changed how a setting behaves, as against whether it survives. Nothing derives that from the code, so it is written by hand: a release that changes an answer you relied on says so in its own entry above, as its own paragraph and never among what is new.