ecbeing: 6 Things to Check First
- Search OS
- ecbeing
ecbeing
6 Things to Check First
| Category | Read Time | Topic | Description | Source | Copyright |
|---|---|---|---|---|---|
| Tips | 8 min read | Japan EC platform guides for search and AI search | When a site built on ecbeing is missing from search or AI search, the cause is usually a decision made at build time. Six checks in order: URL design, rendering, metadata management, WAF and robots.txt,... | searchos.io/en/blog | © 2026 Search OS |
When a site built on a large package like ecbeing is missing from search or AI search, the cause is more often a build-time design decision than the content. URL design, the rendering method, and how metadata is managed are the kind of things that, changed later, become a project the size of a site move. In a renewal that replaces the backend integration and changes tens of thousands of URLs at once, redirect design decides what stays indexed and what traffic survives.
This article pulls the six checks a site owner should run first out of our two ecbeing articles. The details live in the articles linked at the end.
1. Are URLs path-based, and does a product URL survive a category change?
If the RFP says nothing, URLs follow the package default, which can be parameter-based or ID-only. Changing URL design after launch is extremely hard; it is the equivalent of a site move. Start by opening product, category, and parameterized URLs in a browser and checking their format and canonical.
What to check | Expected state |
|---|---|
Product, category, and content URLs | Path format, not parameters |
Product URL | Uniquely identifies the product and does not change when the category changes |
Category URL | Reflects the hierarchy; redirects after a hierarchy change can be set from the admin panel |
Trailing slash and letter case | Unified, with non-canonical forms redirected |
Parameterized URLs (sort, filter, pagination) | A canonical rule is defined |
2. Is product information in the HTML with JavaScript disabled?
Most AI crawlers do not execute JavaScript. A client-side rendered site looks like an empty page to them. Rendering is the hardest item to change after launch, because it means rebuilding the front end. The check itself is simple: disable JavaScript, open a product page, and confirm the product name, price, and structured data are in the HTML.
Product name, price, stock, description, breadcrumbs, and structured data are in the HTML response without executing JavaScript (server-side rendering or static generation)
If client-side rendering is used, there is a mechanism that returns equivalent HTML server-side for search engines and AI crawlers
Before the build, ask for an HTML sample of a product page with JavaScript disabled to be attached to the proposal
Data point: a Korean ecommerce brand with roughly ₩40 billion (about ¥4 billion) in annual revenue left its original code untouched, added a separate rendering layer, and grew organic purchase revenue from about ₩92 million to about ₩166 million (+80%) in three months.
3. Can title, canonical, and structured data be changed from the admin panel?
If the admin panel can't set them, every metadata change becomes a development request, and retrofitting the admin panel after launch is hard. Change a setting in the admin panel and confirm it appears on the page. Check structured data types and values with the Rich Results Test.
Item | Expected state |
|---|---|
title, meta description, canonical, noindex, OGP | Settable per product, category, and content item from the admin panel |
Fallback templates (auto-generation rules) | Editable per page type from the admin panel |
Product, BreadcrumbList, Organization, Article | Output dynamically from product data |
Structured data on/off | Switchable from the admin panel without development |
Same type on the same page | Not output twice |
4. Are the WAF and robots.txt blocking crawlers?
Default WAF settings can block crawlers. A noindex or Disallow: / set on staging and left in production is one of the most common failures in a large renewal. Check the contents of robots.txt, and confirm in server logs that Googlebot and AI crawlers receive a 200.
The allowlist for the WAF, bot protection, and rate limiting includes the verified IPs of search engines and AI crawlers, and the update procedure is in the operations manual
robots.txt can be edited from the admin panel or without a deploy
AI crawlers (GPTBot, ClaudeBot, PerplexityBot, and others) can be allowed or denied per crawler in robots.txt
Right after cutover, no staging noindex or Disallow remains in production
5. Do renewal redirects reach the new URL in a single 301?
In a renewal covering 30,000 products, 2,000 categories, and 5,000 content pages, every URL changes. Setting them all by hand is impossible, so the design is rules for 90% and a mapping table for the remaining 10%. Chained redirects (old → intermediate → new) leak ranking signals and waste crawl. Before cutover, verify every URL mechanically on staging.
Type | Example rule | Share a rule can cover |
|---|---|---|
Products | Old /item/{oldID} → new /products/{newID}; the old-to-new ID map lives in the database | 90% or more |
Categories | Old /cat/{oldCode} → new /category/{newPath}; needs a mapping table | 70–80% |
Content | Old /content/{oldID} → new /contents/{newSlug} | 50–70% |
Campaigns | Ended campaigns go to the matching category on the main site | Individual |
Static pages | Individual | Individual |
For verification, request the full old-URL list against the staging site, extract everything that isn't a 301 (404, chained 301, 302, 200), fix it, and repeat until every URL reaches a 200 page in one 301. On cutover day, open the top 50 URLs by search traffic and backlinks by hand, resubmit the sitemap in Search Console, and request indexing for the main pages. Redirects don't end on cutover day: keep them at least one year, and permanently while backlinks remain.
6. Can the site owner access the sitemap and the access logs?
Only logs tell you what bots actually fetch. Under some operations contracts the logs sit with the vendor and the site owner can't get them directly, which leaves no way to confirm how the site is handling AI search. Register the sitemap in Search Console and confirm the discovered URL count is close to the number of published pages.
Item | Expected state |
|---|---|
XML sitemap | Generated automatically; includes products, categories, and content; excludes unpublished and discontinued items; lastmod reflects the update time |
Over 50,000 URLs | Split, with a sitemap index |
canonical | Output on every page; parameterized URLs follow the rule from check 1 |
Access logs | Web server or CDN logs with User-Agent, response code, URL, and timestamp, retrievable by the site owner |
Post-migration monitoring | Week 1: 404s and redirect errors in Search Console. Month 1: index count trend. Month 3: search traffic back to the previous level |
Search OS keeps watching the post-launch state
Search OS continuously verifies the state behind these six checks on sites built on large packages such as ecbeing. It watches changes in 404s, redirect chains, canonical, and index counts, and the mapping between old and new URLs that bots fetch. Items that drifted since launch and pages lost in a renewal are organized as fix targets. It does not replace the build or the renewal itself. Who keeps watching the requirements after launch is something to settle at the contract stage.
Questions to ask first
Are product URLs path-based, and do they stay the same when a category changes?
With JavaScript disabled, are the product name, price, and structured data in the HTML?
Can title, canonical, noindex, and structured data be changed from the admin panel without a development request?
Do server logs show Googlebot and AI crawlers receiving a 200?
Is any staging noindex or
Disallow: /left in production?After the renewal, does each old URL reach a 200 page on the new URL in a single 301?
Does the contract let the site owner retrieve web server or CDN access logs directly?
Conclusion
When an ecbeing site is missing from search or AI search, look at build-time design before content. URL design, rendering, and metadata management can only be decided before the build. Bot access control, redirects, sitemaps, and logs keep drifting after launch with each feature addition and WAF change. An RFP only guarantees the state at delivery, so confirm the maintenance contract covers keeping the requirements and checking them on every change, and decide in advance who finds the drift.
Related reading
References
Google Search Central: JavaScript SEO basics
Google Search Central: URL structure best practices
Google Search Central: Verifying Googlebot and other Google crawlers
Google Search Central: Site moves with URL changes
Google Search Central: Redirects and Google Search
Google Search Central: Large site owner's guide to managing your crawl budget