Skip to content

Troubleshooting

What goes wrong once SEO Suite Pro is running, and what each symptom means.

If SEO Suite Pro will not open at all (a blank page, or a bounce back to the dashboard), that is an install problem rather than an SEO Suite Pro one. See troubleshooting an install.

Whatever the symptom, SEO Suite Pro wrote down what it did and what it refused to do, in a file your own admin downloads in one click. See what Kyvero extensions log. Turning Detailed logging on from the suite's screen opens a two-day window of much more detail, and closes it again by itself.

An area's screen is refused

You can open SEO Suite Pro but not one of the five areas.

Each area is its own route with its own permission. The user group that installed the suite was granted all six; every other group has to be given them by hand. The list is on the install page.

Nothing happens on the storefront

Check the area's own Status, on the area's screen. That switch, and nothing else, decides whether the area does anything on the storefront. The suite's own switch on Extensions → Extensions → Modules → SEO Suite Pro is what OpenCart's extension list shows; it does not turn an area on or off.

On a multi-store install, every area's switch except the XML sitemap's is per shop: pick the shop from Store at the top of the area's screen and check it there too. The settings reference marks which is which.

After an upgrade, all six switches are off again, on every shop. That is deliberate: an upgrade comes back the way a fresh install arrives, with nothing running until you turn it on. Everything else you set comes back as you left it, and nothing you accumulated is affected. See what an update keeps.

The sitemap says it could not write

The screen names which of three problems it is, with the path:

  • The web root is not a directory. Rare, and usually a misconfigured document root.
  • The web root is not writable by the web server. This is the usual shared-hosting case. Make the directory writable, or upload a robots.txt yourself and make that one file writable.
  • The file is not writable. Make it writable and try again.

In every case anything you typed has been saved and will be written the moment it can be. You are not retyping your crawl rules.

There is no way around this from inside OpenCart. A robots.txt has to be a real file: your web server answers for a file that exists and OpenCart never sees the request, so there is no route that could serve one instead. See limits.

The run finished but published nothing

The screen says so, and the cause is almost always that the store has no keyword URLs to advertise.

  1. Check that SEO URLs are on, under System → Settings → Server.
  2. Check that your products, categories and information pages actually have keywords. If they do not, that is what URLs & meta is for.

An entity with no keyword is left out deliberately: a sitemap advertising a page that 404s is worse than one that omits it.

No scheduled run has ever happened

The screen tells you when the last scheduled run started. If the answer is never:

Your host may not be calling OpenCart's cron.php. The suite registers one hourly job on OpenCart's own scheduler, listed under Extensions → Cron Jobs, and that job is what asks your cycle whether a run is due. A scheduler nobody calls looks exactly like a cycle that has not come round, and no extension can tell the two apart for you.

On OpenCart 4.1.0.4 it cannot fire at all. That release's cron.php crashes inside OpenCart before any extension is reached, so every scheduled task on the store is dead, ours and everybody else's. The screen names the release and says so. The door that release leaves you is a crontab line; it is on the install page.

Either way, Generate sitemap on the screen still writes the same document.

Generate says a run is already going

A scheduled run is writing the sitemap right now, and two writers appending to one file would double every URL in it without either of them erring. Wait for it, or leave it: it carries on by itself and finishes.

Alt text says the rewrite did not apply

Your theme's image markup is not one this area can match, so it rewrote nothing at all rather than rewriting the wrong thing.

The rule needs both kinds of product image to be recognisable: the one a card renders and the ones a product page's gallery renders. A theme is free to move that markup around and is not free to render a different variable, so the usual cause is a theme that has replaced the image markup wholesale.

The screen tells you rather than leaving you to wonder why a page never changed, because mislabelling an image is worse than not improving it, and the person who pays for the difference uses a screen reader.

Your descriptions are not lost by this. They are stored and they come back the moment the theme is one the rule can read.

A product page shows no descriptions but the category listing does

OpenCart builds a product page's additional images as a list carrying no identifiers, and silently skips any whose file is missing from disk. Where the stored rows cannot be lined up against what the page actually renders, nothing is emitted for that product, main image included.

The usual cause is exactly that: a product_image row whose file is no longer on disk. Find it on the product's form and remove it, and the page lines up again.

This is deliberate. A page where some photographs are described and the rest silently are not is one you cannot tell from a working one. See limits.

A generated description has a gap in it

A pattern that renders to nothing writes nothing, and a missing value takes its stranded separators with it, so no description comes out as Chair, , image 2 of 3.

If a whole run reports that it left everything undescribed, the pattern probably rendered empty for that language. Check that a pattern is saved for every language you ticked.

Broken URLs are not being recorded

OpenCart's own SEO URLs have to be on, under System → Settings → Server. With them off, core looks no keyword up at all, and re-resolving anyway would log every URL in your store as broken.

Serving a redirect does not depend on that setting. Only recording does.

A renamed slug did not get captured

Capture renamed slugs is off on a fresh install. If it is on and a rename still produced nothing, there are three deliberate silences:

  • The old keyword still resolves. Two entities swapping slugs, or a second language still spelling it the same way, look exactly like a rename from the outside. Nothing is written while the old URL still works, because a redirect on a path that still resolves would take a working URL off your store.
  • You had already decided about that path. A path you ignored, or gave somewhere to go by hand, is never overwritten by a capture.
  • The capture would have closed a loop. It writes nothing rather than raising a refusal on a product save nobody is looking at. The URL is still broken, so it is recorded as a miss the first time anybody asks for it.

A deleted page is the fourth case and is not a silence: its URL joins the list of broken ones at no hits, because there is nothing this extension could choose on your behalf for a page that is gone.

Check what the network cached. Facebook, LinkedIn and X all cache a preview and will keep showing you an old one until you ask them to re-fetch. Every one of them has a debugger that does exactly that.

If the tags genuinely are not there, view the page's source and look immediately before </head>. If there is nothing there at all:

  • The area is off.
  • The page is not one of the five that can describe itself. Products, categories, brand pages, information pages and the home page can; search results, account pages and the checkout carry nothing and never will.
  • Your theme has replaced core's header and the page has no </head> to splice before. A page like that comes back exactly as it was, because emitting nothing is the only answer that cannot make it worse.

If some tags are there and others are not, that is usually working as intended: a family with nothing to say emits nothing, the price tags are a pair or neither, and a brand page can only say its name and its address.

A search engine says the star rating is invalid

It is not coming from here. This extension claims a rating only where your store has reviews switched on and the product has approved reviews, and it never invents one, because a rating with nothing behind it is a violation rather than an inaccuracy.

Check whether your theme is emitting a Product block of its own. If it is, turn Product structured data off here and keep the theme's, or the other way round, but not both.

Still stuck

Contact support and attach the log, which is one click from the suite's screen.