EC-CUBE Not in Search: Five Checks

A site run on EC-CUBE 2 for ten years moves to EC-CUBE 4 and rankings drop across the board. A new EC-CUBE 4 site returns a 404 for /sitemap.xml when you try to register it in Search Console. An SEO plugin is installed, but nobody knows whether it's enough or whether structured data should be built in-house. An agency was told "please consider SEO too" and answered "we'll handle it", and nobody can see what that covers. Questions from EC-CUBE merchants cluster around these four situations.

What they share is that EC-CUBE assumes you provide things yourself. The sitemap most Japanese hosted carts generate automatically is not built into EC-CUBE 4. Structured data comes from a plugin or a template, and neither keeps checking whether the output is still correct. This article gathers four separate articles into five checks, in order. Numbers and steps come from those articles unchanged; the detailed work lives in the links at the end.

1. If you're migrating from EC-CUBE 2 to 4, treat it as a site move and check the handover table for four assets

A migration from 2 to 4 is a site move, not a version upgrade. The URL structure changes and templates are rebuilt. Plugins and customizations from 2 don't run on 4. Ten years of search performance sits on the old URLs and is lost unless carried to the new ones. The only thing that carries over because both are EC-CUBE is product data; to a search engine, a site is a set of URLs and HTML, and all of that is rebuilt.

Don't switch over until the handover table exists. Before migrating, record the number of URLs with search traffic, main-page rankings, and structured data types. One week after, old URLs should return almost no 404s or redirect errors, and URL Inspection on main pages should show new URLs indexed with the canonical pointing to the new URL. One month after, the sitemap's discovered count should be close to the product count; one to three months after, search traffic should be back to its previous level. Changing the domain at the same time makes causes hard to separate, so migrate first and change the domain once things are stable.

2. If /sitemap.xml returns 404, choose between a plugin, a custom build, and external generation

EC-CUBE 4 doesn't generate an XML sitemap by default. The sitemap.php that existed in 2 is gone in 4, which is why many shops feel it "disappeared" during migration. Most hosted carts generate one automatically; on EC-CUBE you provide it yourself. The options are a plugin, a custom build, or an external tool, and the choice depends on product count, update frequency, and whether you have developers.

Under 10,000 products, use a plugin; above that or with special requirements, build your own; external generation is a stopgap. For a plugin, check that it supports your version (4.0/4.1/4.2/4.3) and check its last update date, because a plugin built for an old version can stop working after a core update. Once the sitemap exists, check that the URL count is close to the number of published products and categories, that unpublished and discontinued products are excluded, that lastmod differs per product, that Search Console reports "Success", and that robots.txt has a Sitemap: line. Keep only one sitemap; a plugin and a custom build together send the same URL with different lastmod values.

3. For SEO plugin structured data, check not whether it outputs but whether it's still correct today

EC-CUBE SEO plugins are reliable for meta tags, OGP, and sitemaps. Structured data is different. The plugin outputs it but has no function that keeps checking whether the output is correct. When a core update, a plugin update, or a template change breaks structured data, nobody notices, and that is the most common failure. Invalid structured data can be worse than none; an error causes the whole block to be ignored.

Plugin output is designed around the product structure of the standard EC-CUBE template, so it drifts most at three points: products whose price or stock varies by variant (size, color), customized templates, and core or plugin updates. Start by running one product page through the Rich Results Test to see whether any failure in the table is happening on your site.

4. Decide whether to own structured data yourself by counting five conditions

Before plugin-versus-in-house comes a different question: whether a mechanism exists that keeps confirming the output is correct. Without one, either implementation repeats the same failures. With that in place, if two or more of the following apply, implement structured data in the template yourself and turn the plugin's output off.

• Products whose price or stock varies by variant make up 30% or more of the catalog

• The template is heavily customized from the standard

• There are content pages (features, editorial) and you want to output Article

• Core or plugin updates happen several times a year

• Structured data has broken before

If one or fewer apply, keep using the plugin's output. Either way, verification is still required: after every update, run one product, one category, and one content page through the Rich Results Test; weekly, sample-check that structured data prices and stock match the page; monthly, check error and warning counts in the Search Console enhancement reports; and watch server logs or bot logs continuously for whether bots can fetch product pages. Up to a few hundred products this works by hand. Past several thousand, with many variants and frequent updates, the routine itself becomes a burden.

5. If you hire an agency, hand over a six-area requirements sheet before the build and accept delivery against the same table

To an agency, SEO is a vague word, and making title editable can count as "handled". A requirements sheet that says what, where, and how to verify for each item makes it clear whether it's in the estimate, and the same table serves for acceptance at delivery. Anything not written down is not included.

Four requirements are especially easy to miss on EC-CUBE. State explicitly that the XML sitemap must be generated automatically, because EC-CUBE 4 has no built-in one. Require that the plugin and template never output the same structured data type twice, verified by counting ld+json blocks in the source. Product name, price, description, and structured data must be in the HTML without JavaScript. In robots.txt, disallow the admin panel, cart, and My Page, and write down a policy for AI crawlers such as GPTBot. Add one sentence at the end: "Each item above will be verified at delivery by the method in the right column. If any item will not be handled, state so at the estimate stage." A higher estimate after that is normal; the items that weren't included have simply become visible.

Search OS keeps watching the state that decays after migration and delivery

A requirements sheet covers the state at delivery; a handover table covers the state at switchover. After that, every added plugin, core update, and campaign page surfaces missed redirects, drift in reimplemented structured data, and stopped sitemap generation. Search OS doesn't change EC-CUBE core or its plugins. It provides metadata, structured data, canonical tags, and sitemaps for search engines and AI crawlers as a separate layer and keeps verifying that they match the visible text. From bot logs it confirms whether Googlebot and GPTBot actually fetch product pages, and it turns broken output, missing Article markup, unfetchable URLs, and metadata lost in migration into a fix list. It doesn't replace the migration or the agency's work; it keeps finding the gaps overlooked after delivery.

Questions to check first

• For a 2 to 4 migration, is there a one-to-one mapping table from old URLs to new URLs, with 301 redirects

• Are pre-migration title, description, and structured data types for main pages recorded in a form you can compare

• Does /sitemap.xml open, is its URL count close to the published product count, and does lastmod differ per product

• Does the sitemap plugin support your EC-CUBE version, and is it still being updated

• When a product page runs through the Rich Results Test, do price and stock match the page

• Is the same JSON-LD type output twice on the same page

• Does the maintenance contract with the agency include keeping SEO requirements, and is it decided who keeps watching after delivery

Conclusion

When an EC-CUBE shop is missing from search, first decide which of four entry points is failing: migration, sitemap, structured data, or the requirements sheet. For migration, the four-asset handover table; for the sitemap, one of three options plus the checks afterward; for structured data, verification that it's still correct today; for an agency build, the six-area requirements sheet. On EC-CUBE, all of these are absent unless you ask for them or provide them, and once in place they decay with every core and plugin update. Everything up to here is a settings question; what follows is keeping the same state through every update.

Related reading

• SEO Assets Lost in an EC-CUBE 2 to 4 Migration

• Three Options for an EC-CUBE 4 XML Sitemap

• How Far Can You Trust EC-CUBE SEO Plugins

• A requirements sheet template for briefing your EC-CUBE agency on SEO and AI search

References

• Google Search Central: Site moves with URL changes

• Google Search Central: Redirects and Google Search

• Google Search Central: Build and submit a sitemap

• Google Search Central: Product structured data

• Google Search Central: Rich result status reports

• Google Search Central: Ecommerce best practices