Ecwid Shopping Cart embeds a hosted store on your WordPress site through a plugin that caches a small set of references locally and pulls everything else from Ecwid's cloud. The local data, store ID, embedded product IDs, embedded category IDs, and last-sync timestamps, lives in wp_options and postmeta. Most admins assume nothing is stored locally and are surprised when an audit reveals dozens of posts referencing products that no longer exist in the Ecwid catalog.

SleekView surfaces those local references as a flat table so admins can audit what is actually on their server. Every post that embeds an Ecwid product or category appears as a row, with the reference ID, sync timestamp, and post status as columns. Filter to embeds older than your sync tolerance and you have the list of pages potentially showing outdated data. Filter to references whose product ID no longer matches anything in the connected catalog and you have the cleanup list for an inventory swap.

The most valuable use case is migration prep. Stores planning a move from Ecwid to a self-hosted commerce stack need to know exactly which WordPress content embeds Ecwid resources, because every embed becomes a manual rebuild target on the new platform. Without a tabular surface, that audit means crawling content one post at a time. With SleekView, it is a single export of every reference, joined with the post title and slug, ready for the migration project plan.

Embed-based commerce plugins like Ecwid sell themselves on the promise that nothing lives locally, the cloud handles the catalog, the orders, and the payments. That is mostly true, but the WordPress side still accumulates a meaningful amount of state: store IDs, embedded product references, embedded category references, sync timestamps, embed configuration. When that state goes wrong, the symptoms appear on the storefront but the cause is buried in postmeta nobody audits.

A discontinued product still shows up on a landing page because the embed reference was never updated. A category renumber on the Ecwid side leaves WordPress posts pointing at the old IDs. A sync outage from six months ago left a subset of pages showing stale cached data that nobody noticed.

None of this is visible from the Ecwid admin because Ecwid does not know about WordPress posts. None of it is easily visible from the WordPress admin because the data lives in meta keys nobody queries. SleekView turns the local crumbs into an audit surface, which is exactly what hosted-store WordPress integrations need but rarely have.