SEO Redirect Manager — User Manual

1. Getting Started

Platform Compatibility

This app is designed primarily for embedded Ecwid stores — stores embedded on your own website using WordPress, Wix, Squarespace, Joomla, or a custom site. On embedded stores, the app's client-side redirect execution and 404 detection work reliably because the host page loads normally and lets Ecwid (and app scripts) run.

Wix users: The app is designed to work seamlessly with Wix stores that support full redirects and 404 detection. It leverages Ecwid's built-in navigation API (Ecwid.openPage()) to make sure redirects properly navigate the page on Wix. To get the most out of it, make sure your redirect destinations include product or category IDs, like /Product-Name-p12345.

Instant Site Users: Client-side redirect execution and 404 detection are unreliable on Instant Site due to Ecwid's control over the server. This control may resolve or reject URLs before the application's JavaScript loads.

Installation

1. Find SEO Redirect Manager in the Ecwid App Market or click here.
2. Click Install. The app requests the following permissions:
   • Read store profile (store URL and settings)
   • Read catalog (product and category data for deletion detection)
   • Customize storefront (inject the redirect script)
   • Public storefront access (serve redirect rules to visitors)
3. After installation, the app appears in your Ecwid admin panel sidebar in the Marketing section.

On first install, the app performs an initial catalog sync — it reads all your products and categories to record their current URLs. This enables automatic redirect creation if you later delete items.

Opening the App

Navigate to Apps > SEO Redirect Manager in the Ecwid admin panel. The app loads inside the admin as an embedded panel.

Admin UI Layout

The app uses a sidebar-based layout with three main sections:

Header Bar

At the top of the screen you'll find the app logo and title ("SEO Redirect Manager for Ecwid"), plus a + Add New Redirect button for quick access from anywhere in the app.

Sidebar Navigation

Dashboard Overview

The Dashboard is your main working area. It includes:

1. Stats Cards — Three cards showing key metrics:
   • Total Redirects — Number of redirect rules in your store
   • 404s Detected — Number of unresolved broken URLs
   • Redirects Hit — Total number of times redirects have been triggered
2. Managed Redirects Table — View, search, and manage all your redirect rules with search bar, filter options, bulk actions, and pagination controls.
3. 404 Detector Panel — A preview of recent 404 errors with quick actions: Create Redirect, Ignore, or View All 404s.

What Happens After You Create a Redirect

When you save a redirect rule, the app:

1. Validates the rule (checks for loops, self-redirects, and conflicts).
2. Stores it in the database.
3. Syncs the updated rules to your storefront via Ecwid Application Storage.
4. Visitors who land on the old URL are immediately redirected to the new one.

No server configuration or code changes are required on your part. The redirect script runs automatically on your storefront.

2. Managing Redirects

The Managed Redirects Table

The Dashboard displays all redirect rules in the Managed Redirects table:

Creating a Redirect

1. Click the + Add New Redirect button in the header bar or the table header.
2. Fill in the form:
   • Source Path (required) — The old URL path, e.g. /store/old-product-name-p12345 or #!/old-product-name for hash-URL stores
   • Destination (required) — The new URL path, e.g. /store/new-product-name-p12345 or #!/new-product-name/p/12345. Enter the URL exactly as it appears in your browser's address bar.
   • Wildcard Pattern (optional toggle) — Enable to redirect an entire path prefix at once. Use * as a suffix in both source and destination — e.g. source /old-category/* → destination /new-category/*. The toggle auto-enables when the source path ends with /*. Exact matches always take priority over wildcard rules.
   • Notes (optional) — A memo for your own reference, up to 500 characters
3. Click Save.

Source paths starting with / have trailing slashes removed and are lowercased automatically. Hash-URL paths starting with #!/ or #/ are preserved as-is (with lowercase normalization). Paths are case-insensitive.

You can enter sources in either format. If your store uses hash URLs (#!/...), you can still enter sources as /old-product — the app automatically matches both /old-product and #!/old-product at runtime. This means you don't need to worry about which URL format your store uses when creating redirects.

Live Destination Verification

As you type in the Destination field, the form queries your store in real time (debounced 600 ms) and shows colour-coded feedback:

Only paths that contain an Ecwid entity ID pattern (-p12345, /p/12345, -c67, /c/67) are checked against the Ecwid API. External URLs (http://…) and arbitrary paths (/contact) skip the API call.

Custom URL Paths

Redirects double as custom URL paths for your store. Ecwid's built-in custom slug feature only works on Instant Site — if your store is embedded on WordPress, Wix, Squarespace, or another platform, you can't set custom product URLs through Ecwid alone. This app fills that gap.

Create a redirect with a clean, memorable source path and point it to any product or category:

Visitors who hit the custom URL path are seamlessly redirected to the product or category page. You can share these custom paths in marketing emails, social media, print materials, or anywhere you want a clean URL.

Tip: Combine custom URL paths with wildcard redirects to create custom paths for entire categories. For example, /shop/* → /Store-Category/* redirects all paths under /shop/ to your store's category structure.

Validation Rules

• No self-redirects — The source and destination cannot be the same path.
• No duplicate sources — Each source path can only have one redirect rule. If a rule already exists for that source, you'll get a DUPLICATE_SOURCE error.
• Loop detection — If redirect A → B already exists and you try to create B → A, the app rejects it to prevent an infinite redirect loop.
• Chain warning — If redirect A → B exists and you create B → C, the app shows a warning suggesting you update A to point directly to C instead. This is a warning, not an error — the redirect is still created.
• Destination existence check — If the destination contains an Ecwid product ID (e.g. /product-name-p12345) or category ID, the app verifies the entity exists before saving. If not found, the redirect is rejected with a DESTINATION_NOT_FOUND error.
• Unverifiable destination warning — If the destination is a plain path (e.g. /contact) with no Ecwid product or category ID, the form shows a yellow warning that the path can't be verified. The redirect is still saved. Saved redirects with unverifiable destinations show a yellow ⚠ Unverified badge in the Status column.

Wildcard Redirects

Wildcard redirects let you redirect an entire category or path prefix with a single rule, instead of creating a separate redirect for every page.

Format: Add * as a suffix to both the source and destination paths. The * matches any path after the prefix, and the matched portion is appended to the destination automatically.

To create a wildcard redirect: Enter the source path with a /* suffix — the Wildcard Pattern toggle will auto-enable. Enter the destination path with a /* suffix, then save.

Priority: Exact match rules always win. If /old-category/featured has its own exact redirect, that rule applies; the wildcard only matches paths that have no exact rule.

Destination verification: Wildcard destinations cannot be verified in real time. The form shows an "Unverified destination" warning — this is expected and the redirect will be saved normally.

Editing a Redirect

1. Click the Source URL link or use the Actions menu (⋮) and select Edit.
2. Modify any field (source, destination, notes).
3. Click Save.

The same validation rules apply to edits.

Enabling and Disabling Redirects

1. Click the Actions menu (⋮) on the redirect row.
2. Select Activate or Deactivate.

Disabled redirects remain in the database but do not execute on the storefront. The status badge shows "Active" (green) or "Inactive" (yellow). The change takes effect immediately.

Deleting a Redirect

1. Click the Actions menu (⋮) on the redirect row.
2. Select Delete.
3. The redirect is removed immediately.

Deleted redirects are permanently removed from the database and from the storefront rules.

Searching

Use the search box above the table to filter redirects. Search matches against both the source path and destination. The search is case-insensitive.

Sorting

Click any data column header to sort the table server-side. The following columns are sortable:

• Source URL — Alphabetical by source path
• Destination URL — Alphabetical by destination path
• Status — By active/inactive state
• Hits — By number of times triggered

You can also sort by Created date and Updated date via the underlying API (default sort is newest first). Click the same column again to toggle between ascending (▲) and descending (▼) order.

Bulk Actions

You can select multiple redirects using the checkboxes and perform bulk operations:

1. Use the checkbox in the header row to select all visible redirects on the current page.
2. Or click individual row checkboxes to select specific redirects.
3. Click Bulk Actions (N) to open the action menu.
4. Choose an action:

Delete requires a two-step confirmation — click Delete, then click Confirm in the inline prompt. Click Cancel to abort. After any bulk action completes, the selection is cleared and the table refreshes.

Pagination

The Dashboard table shows a preview of your redirects. Use the pagination controls at the bottom to navigate between pages.

"Destination Broken" Warning

If a redirect's destination points to a product or category that has been deleted, the redirect is marked with a "destination broken" indicator. The redirect still functions (visitors are sent to the destination URL), but you may want to update it to point to an active page.

3. Bulk CSV Import

Bulk CSV import lets you upload a CSV file to create many redirects at once instead of adding them one by one.

CSV Format

Your CSV file must have a header row with these columns:

Example CSV

source_path,destination_path
/store/summer-sale-c5678,/store/winter-sale-c5678
/store/blue-widget-p12345,/store/blue-widget-v2-p12345
/store/promo,/store/deals
/store/old-category/*,/store/new-category/*

Column headers are case-insensitive and trimmed of whitespace. Wildcard redirects are auto-detected from source paths ending with *.

Import Workflow

Step 1: Upload

Click Choose File or drag and drop a .csv file.

Step 2: Preview

After uploading, the app parses the CSV and shows a preview table of up to 100 rows. The Status column uses colour-coded pill badges:

Error rows have a red background; unverified rows have a light yellow background.

Common row-level errors:

• Missing source_path or destination_path
• Source and destination are the same (self-redirect)
• Empty fields

Step 3: Import

Click Import to submit the valid rows. The backend performs additional validation: loop detection, chain detection, and duplicate source handling.

Step 4: Results

After import, a summary card shows:

Each error includes the row number, source path, error message, and error code.

Tips

• Fix errors in your CSV file and re-import. Already-created redirects will be skipped as duplicates.
• The import processes rows sequentially. If one row fails, subsequent valid rows still get created.
• Large files are accepted, but the preview displays only the first 100 rows.
• All imported redirects are labeled with the "Manual" origin.
• Wildcard redirects are auto-detected from source paths ending with *. Wildcard rows display a blue wildcard badge in the preview table.

4. Broken URLs & 404 Detection

The 404 Errors page (accessible from the sidebar) shows pages on your storefront that visitors tried to access but resulted in a 404 (page not found) error. You can review these broken URLs and create redirects to fix them.

Quick Access from Dashboard

A 404 Detector Panel at the bottom of the Dashboard shows the most recent unresolved 404 errors. From here you can:

• Create Redirect — Quickly fix a broken URL
• Ignore — Dismiss expected 404s
• View All 404s — Navigate to the full 404 Errors page

How Detection Works

The app's storefront script uses three mechanisms to detect broken URLs:

1. Ecwid.OnPageLoaded listener — When Ecwid reports that a page type is empty or explicitly PAGE_NOT_FOUND, the script reports it as a 404.
2. Root-category fallback detection — On SPA-hosted stores (Cloudflare Pages, Vercel, Netlify, etc.), Ecwid may show the main catalog (root category) for unrecognized URLs instead of reporting a 404. The script detects this by checking: if Ecwid loads the root category (CATEGORY type with categoryId: 0) but the browser's URL path doesn't match the store's base path, it's treated as a 404. The store's base path is read from window.ec.config.baseUrl when available.
3. Hash change fallback — For hash-based URLs like #!/product/nonexistent-slug, Ecwid may not fire OnPageLoaded with a 404 type. Instead, it falls back to showing the catalog (type CATEGORY). The script detects this mismatch — if the URL requests a product but Ecwid loads a category page, it's treated as a 404.

Key details:

• Detection is automatic — no configuration needed.
• Reports are batched and debounced (3-second window) to avoid excessive requests.
• Each unique broken URL is recorded once. Repeat visits increment the hit count.
• The referrer (the page that linked to the broken URL) is captured when available.

Platform Compatibility

404 detection is designed for embedded stores (WordPress, Squarespace, Joomla, custom sites) where the host page always loads the Ecwid storefront widget and app scripts. On these embedded stores, all detection mechanisms work reliably.

Wix stores: 404 detection is available on Wix with some limitations. Ecwid runs inside a Wix TPA iframe, so the app uses a segment-count guard to filter false positives: the normal Wix store root has 3 path segments, so only paths with 4+ segments are treated as real 404s. Both detection mechanisms (empty page type and root-category fallback) are active on Wix with this guard.

Instant Site stores: 404 detection is not available on Ecwid Instant Site. Ecwid controls the server on Instant Site and may return a static 404 page that does not load the Ecwid SDK or any app scripts. Because the app's JavaScript never executes on these pages, broken URLs cannot be detected client-side.

For Instant Site stores, the admin UI automatically hides 404 detection features and shows an informational message explaining this limitation. Webhook-based features (automatic redirect for deleted products) continue to work on all platforms.

The 404 Errors Page

The 404 Errors page displays a table with these columns:

Searching

Use the search box to filter by URL path or referrer text. The search is case-insensitive.

Filtering

Use the status filter dropdown:

• Unresolved (default) — Shows only broken URLs that haven't been fixed yet.
• Resolved — Shows broken URLs that have been addressed.
• All — Shows everything.

Sorting

Click a column header to sort. Available sort options: last seen, first seen, hit count, URL path.

Bulk Actions

Select multiple records using the checkboxes and click Bulk Actions (N) to delete them all at once. Deletion requires a two-step inline confirmation.

Pagination

The table shows 25 records per page.

Fixing a Broken URL

Option 1: Create a Redirect (Recommended)

1. Find the broken URL in the table.
2. Click Create Redirect.
3. An inline form appears with the source path pre-filled.
4. Enter the destination — the correct page visitors should reach.
5. Click Create.

The app creates the redirect, marks the broken URL as resolved, and syncs the rule to your storefront. Future visitors landing on that URL will be redirected.

The redirect note is automatically set to include the hit count, e.g. "Created from broken URL (47 hits)".

Option 2: Resolve Without Redirecting

If the 404 is expected (e.g., you intentionally removed a page), click Resolve to mark it as handled without creating a redirect. The broken URL moves to the Resolved filter.

Option 3: Delete

Click Delete to remove the broken URL record from the log entirely. This does not affect any existing redirects.

Limits and Cleanup

When the 10,000 record limit is reached, the oldest records are automatically removed to make room for new ones.

5. Automatic Redirects

The app can automatically create redirects when you delete a product or category from your Ecwid store. When a product is removed, its URL stops working — any bookmarks, backlinks, or Google search results pointing to it will lead to a 404 error. Automatic redirects prevent this by creating a redirect from the deleted product's URL before visitors notice the broken link.

How It Works

1. You delete a product or category in your Ecwid admin.
2. Ecwid sends a webhook notification to the app.
3. The app looks up the deleted entity's last known URL (recorded during initial sync or previous updates).
4. The app automatically creates a redirect from the old URL to a fallback destination (e.g., the parent category page or your store's homepage).
5. The redirect is synced to your storefront immediately.

The entire process happens in the background within seconds of the deletion.

Works on all platforms. Deletion detection is server-to-server (via Ecwid webhooks) and works on both embedded stores and Instant Site. However, the client-side redirect execution that makes the old URL redirect to the new destination is only reliable on embedded stores. On Instant Site, the redirect rule is created and stored, but may not execute if Ecwid's server handles the URL before the app's JavaScript loads.

Initial URL Sync

When you first install the app, it reads all your products and categories and records their current URLs. This baseline is necessary so the app knows where deleted products were located. The sync runs once automatically on installation.

Auto-Redirect in the Redirect List

Auto-created redirects appear in the Dashboard's Managed Redirects table with the Auto origin label. They behave the same as manually created redirects — you can edit the destination, disable, or delete them.

Enabling and Disabling Automatic Redirects

Automatic redirects can be toggled on or off in the Settings page (accessible from the sidebar) under the Automatic Redirects section. When disabled:

• Product and category deletions are still detected by the app.
• No redirects are automatically created.
• You can re-enable it at any time. Future deletions will generate auto-redirects again.

Deduplication

If Ecwid fires multiple webhook events for the same deletion in quick succession, the app deduplicates within a 5-second window. Only one redirect is created per deleted entity.

6. How Redirects Work

This chapter covers the technical details of how the app executes redirects on your storefront.

Client-Side Redirect Execution

The app injects a small JavaScript file (under 5KB) into your Ecwid storefront. This script runs on every page load and performs the following:

1. Wait for Ecwid API — The script waits for Ecwid.OnAPILoaded before reading config. It attempts an early call wrapped in try/catch (the API throws an error if not yet initialized), then falls back to the OnAPILoaded callback.
2. Load rules — Reads redirect rules from Ecwid Application Storage (Ecwid.getAppPublicConfig). This data is already available on the page — no extra network request is needed.
3. Normalize the current URL — For clean-URL stores, strips query strings, fragments, and trailing slashes. For hash-URL stores (#!/... or #/...), preserves the hash prefix and normalizes only query strings and trailing slashes. Converts to lowercase.
4. Exact match — Checks the current URL path against all exact-match redirect rules. First tries a direct lookup, then uses suffix matching to handle embedded stores where the full URL includes a platform-specific base path (e.g., /my-store/online-store/old-product matches the redirect source /old-product).
5. Cross-format match — If no exact match, tries the alternate URL format (/path ↔ #!/path).
6. Wildcard match — If still no match, checks against wildcard pattern rules sorted by specificity (longest prefix first).
7. Redirect — If a match is found and the rule is active, the script navigates the visitor using the best available method:
   • Product/category destinations: Uses Ecwid.openPage() to navigate via Ecwid's internal routing. This works correctly on all platforms, including Wix where the script runs inside an iframe.
   • Hash-URL destinations (starting with #): Sets window.location.hash to trigger Ecwid's SPA router.
   • Other destinations: Falls back to window.location.replace(destination).
   For SPA navigation (Ecwid.openPage and hash changes), the script temporarily hides the storefront to prevent a flash of the wrong content while the target page loads. The storefront reappears once the target page has rendered.
8. SPA re-check — The script listens for hashchange events and re-runs matching on every hash navigation. This ensures redirects work even when Ecwid changes the hash after initial page load.

If no match is found, the script exits silently with no impact on page performance.

Testing Redirects from the Admin UI

The Test URL page (sidebar navigation) lets you simulate which redirect rule would fire for any URL path — without visiting your storefront.

Enter a store-relative path (e.g. /old-product-name or #!/old-slug) and click Test. The result shows:

• Match found / No match — whether any active rule would redirect this URL.
• Redirect chain — each hop in sequence, with the match type badge (exact, suffix, or wildcard) and the resolved destination. For wildcard rules, the actual substituted destination is shown (e.g. /new-category/product-a rather than /new-category/*).
• Final destination — the URL the visitor would ultimately land on.
• Warnings — a loop warning if the chain is circular, or a chain warning if there are multiple hops (which adds latency).

This is particularly useful for:

• Verifying wildcard rules match the URLs you expect and produce the right resolved destination.
• Debugging chains: if a rule points to a destination that is itself a source, the full path is shown.
• Confirming that a rule is active before going live.

Debugging Redirects (browser console)

If a redirect isn't working as expected on your storefront, you can activate diagnostic logging by adding ?srm_debug=1 to any storefront URL. This outputs detailed [SRM] messages to the browser console showing:

• Whether the config was loaded from Application Storage
• The current URL path being matched
• Each suffix matching attempt and its result
• Which redirect execution method was used

Open the browser developer console (F12 → Console tab) to see the output.

URL Matching Rules

Path Normalization

Before matching, all paths are normalized:

• Clean URL paths (/...): leading slash is ensured, trailing slash is removed, converted to lowercase, query strings and non-Ecwid fragments are stripped. /Store/My-Product/ and /store/my-product are treated as the same path.
• Hash-URL paths (#!/... or #/...): the hash prefix is preserved, trailing slash is removed, converted to lowercase, query strings are stripped. #!/Old-Product-Name becomes #!/old-product-name.

Exact Match vs Wildcard

• Exact match rules match a single specific path. Example: /store/old-product-p123 matches only that exact path.
• Wildcard rules use * as a suffix to match any path that starts with the given prefix. Example: /store/old-category/* matches /store/old-category/product-a, /store/old-category/product-b, etc.

Exact match rules always take priority over wildcard rules. If both match, the exact rule wins.

Wildcard Source Format

The source path must end with /* (e.g. /store/old-category/*). The prefix is everything before the /*.

Destination Substitution

The destination must also end with *. When a wildcard rule matches, the portion of the URL path that was captured by * is appended to the destination prefix.

Example:

• Source: /old-cat/*, Destination: /new-cat/*
• Visitor hits /old-cat/red-shoes-p123 → matched portion is red-shoes-p123 → redirected to /new-cat/red-shoes-p123
• Visitor hits /old-cat/summer/sandals-p456 → matched portion is summer/sandals-p456 → redirected to /new-cat/summer/sandals-p456

Specificity Ordering

When multiple wildcard rules could match the same URL, the rule with the longest prefix wins. For example, if both /store/* and /store/sale/* exist, a URL like /store/sale/item-p99 matches /store/sale/* (more specific).

Cross-Format Matching for Wildcards

Wildcard matching applies to both clean URLs and hash-URL formats. A wildcard source /old-cat/* also matches hash-URL paths like #!/old-cat/product-name. The matched suffix is extracted and appended to the destination in the same format.

Supported URL Formats & Cross-Format Matching

Ecwid stores can use two URL formats:

• Clean URLs: /store/product-name-p12345
• Hash-based URLs: #!/product/product-name or #/product/product-name

The app handles both formats natively with cross-format matching. You can enter sources in either format — the storefront script automatically tries both at runtime. A source entered as /old-product will match visitors on both /old-product (clean URL) and #!/old-product (hash URL). This means you don't need to know which URL format your store uses.

For hash-URL stores, the redirect script also monitors hashchange events so that redirects work during SPA navigation, not just on initial page load.

Embedded Store Path Matching

When your Ecwid store is embedded on a website (WordPress, Wix, Squarespace, etc.), the store is mounted at a sub-path like /my-store/online-store. You enter redirect sources as simple store-relative paths like /old-product, but the full browser URL is /my-store/online-store/old-product.

The app handles this automatically using suffix matching — it checks if the current page URL ends with your redirect source path. This works on any platform without needing to configure the store's base path, and works even if your store is embedded on multiple sites simultaneously with different base paths.

Application Storage and the 256KB Limit

The app performs redirects entirely in the visitor's browser via the storefront script — not on a server. That script needs to know your redirect rules on every page load, but it cannot make an authenticated call to the app's backend each time (that would add latency and create a dependency on an external server being available).

Instead, redirect rules are published to Ecwid Application Storage — a key-value store built into every Ecwid store. The public config key is readable in the browser with no authentication via Ecwid.getAppPublicConfig(), served by Ecwid's own infrastructure. When the storefront script runs, the rules are already available on the page with no extra network request needed.

The app's backend is the source of truth (PostgreSQL). Application Storage is the distribution layer that makes rules available to the browser script cheaply and reliably.

Ecwid imposes a 256KB limit on public Application Storage. For most stores, all redirect rules fit within this limit.

Overflow Mode

When your redirect rules exceed 256KB, the app switches to overflow mode:

1. Application Storage stores only a lightweight marker containing a hash and an API endpoint URL.
2. The storefront script detects the overflow marker.
3. It fetches the full rules from the app's backend API.
4. The fetched rules are cached in sessionStorage using the hash as a cache key.
5. On subsequent page loads within the same browser session, rules are served from sessionStorage (no network request).
6. If the hash changes (rules were updated), the cache is invalidated and fresh rules are fetched.

Overflow mode adds a small delay on the first page load of a session (one network request). Subsequent pages load instantly from cache.

Platform Compatibility

The app's client-side redirect execution and 404 detection work reliably on embedded stores (including Wix) but not on Instant Site.

Why the difference? On embedded stores, the host website (e.g. WordPress) returns HTTP 200 for all pages and lets the Ecwid widget handle routing client-side. The app's storefront script loads on every page and can intercept URLs before the visitor sees the content.

On Wix, Ecwid runs inside an iframe (Wix TPA). The app's script still loads and executes redirects using Ecwid.openPage() to ensure the parent page navigates correctly. However, 404 detection is disabled on Wix because Ecwid fires incorrect page-not-found events on the normal store page within the iframe, causing false positives.

On Instant Site, Ecwid controls the web server. The server may resolve or reject a URL (returning a 404 page or redirecting) before the page loads and before the app's JavaScript has a chance to run. Static 404 pages on Instant Site do not load the Ecwid SDK or app scripts at all.

Automatic detection: The app detects your store platform on installation and on first admin load by checking the Ecwid store profile. If instantSiteUrl is present, the store is classified as Instant Site. The admin UI adjusts which features are shown accordingly.

Error Handling

The storefront script is designed to never break your store:

• All redirect logic is wrapped in error handling. If anything fails, the page loads normally.
• Errors are reported to the app's backend for monitoring (fire-and-forget — no impact on page load).
• No console errors are shown to visitors.

7. Troubleshooting

Redirect Not Working

The redirect is enabled but visitors are not being redirected.

1. Check the status. Open the Dashboard and confirm the redirect shows "Active" status.
2. Check the source path. Make sure the source path matches the actual URL visitors are using. Paths are normalized (lowercase, no trailing slash). You only need to enter the store-relative path (e.g., /old-product), not the full URL — the app uses suffix matching to handle platform base paths automatically.
3. Check the destination format. For best results on all platforms (including Wix), ensure your destination URL contains the Ecwid product or category ID. For example: /New-Product-Name-p813605964 (the -p813605964 part is the product ID).
4. Wait for sync. After creating or editing a redirect, the app syncs rules to your storefront. This typically happens within a few seconds. Try a hard refresh (Ctrl+Shift+R / Cmd+Shift+R) on your storefront.
5. Clear browser cache. Your browser may have cached the old page. Clear your cache or test in an incognito/private window.
6. Check for conflicting redirects. Search for the source path in the Dashboard's Managed Redirects table. If multiple rules involve the same path, there may be a conflict.
7. Verify the storefront script is loaded. Check your Ecwid admin to confirm the app is installed and the storefront customization is active. The redirect script must be loaded for client-side redirects to work.
8. Use debug mode. Add ?srm_debug=1 to the source URL (e.g., https://yourstore.com/store/old-product?srm_debug=1) and open the browser console (F12 → Console). Look for [SRM] messages that show what the script is doing — whether config is loaded, which paths are being matched, and whether a redirect is attempted.

Redirect Not Working on Hash-URL Store

Your store uses hash URLs (#!/...) and redirects are not executing.

1. Either URL format works for sources. You can enter the source as /old-product-name or #!/old-product-name — the app matches both formats automatically. For destinations on hash-URL stores, use the hash format (e.g. #!/new-product-name/p/12345) as it appears in your browser's address bar.
2. Hard refresh after creating the redirect. Press Ctrl+Shift+R (Cmd+Shift+R on Mac) to clear cache and reload the storefront script.
3. Check that the Ecwid API has loaded. The redirect script waits for Ecwid's API to initialize before reading rules. If the Ecwid widget fails to load, redirects cannot execute.
4. Test by navigating directly. Paste the full source URL into the browser address bar and press Enter. The redirect should execute within a moment.

404s Not Being Detected

The 404 Errors page is empty even though your store has broken links.

1. Visit the broken URL. 404 detection only triggers when someone actually visits a broken page. Open the broken URL in your browser to generate a report.
2. Wait for batching. 404 reports are batched with a 3-second debounce. The broken URL should appear within a few seconds of visiting it.
3. Clear browser cache. The storefront script is cached by the browser. After an app update, old versions of the script may continue running until the cache expires. Test in an incognito/private window to ensure you're running the latest version.
4. Check rate limits. The app accepts up to 100 broken URL reports per store per hour. If your store has heavy bot traffic hitting many 404 pages, some reports may be rate-limited.
5. SPA hosting edge case. On stores hosted with SPA fallback (Cloudflare Pages, Vercel, Netlify), the host serves the main page for all URLs. The app detects this by comparing the URL path against the store's expected location. If your store is embedded at a sub-path (e.g. /shop) rather than the root (/), ensure window.ec.config.baseUrl is set in your Ecwid embed code so the app knows which path is legitimate.

CSV Import Errors

The import preview shows errors on some rows.

The CSV fails to parse at all:

• Ensure the file is a valid .csv with comma-separated values.
• The first row must be a header: source_path,destination_path
• Column headers are case-insensitive but must match the expected names.

Backend errors after submitting:

• REDIRECT_LOOP — One of the rows creates a redirect loop with an existing rule.
• DUPLICATE_SOURCE — A redirect for that source path already exists. The row is skipped.

Chain and Loop Warnings

"Creating this redirect would cause a loop."

A redirect loop means A → B → A (or longer cycles). The app rejects loop-creating redirects. To fix:

1. Delete or modify the existing redirect that conflicts.
2. Create the new redirect after the conflict is resolved.

"This redirect creates a chain: A → B → C."

A chain is not an error — the redirect is created. But chains add an extra hop for visitors. The app suggests updating A to point directly to C. You can:

1. Edit redirect A to change its destination from B to C.
2. Leave it as-is if the chain is intentional.

Redirect Shows "Destination Broken"

This means the product or category that the redirect points to has been deleted from your Ecwid store. The redirect still functions (sends visitors to that URL), but the destination page no longer exists.

To fix:

1. Edit the redirect and change the destination to an active page.
2. Or delete the redirect if it's no longer needed.

Redirects Not Working on Wix

The redirect is enabled but visitors see the main store page instead of being redirected on Wix.

On Wix, the app's storefront script runs inside an Ecwid iframe. The app uses Ecwid.openPage() to navigate, which handles the iframe boundary correctly. If redirects are not working on Wix:

1. Check the destination format. The destination URL must contain a recognizable Ecwid product or category ID for Ecwid.openPage() to work. Supported formats:
   • Product: /Product-Name-p813605964 (clean URL with -p{id}) or #!/Product-Name/p/813605964 (hash URL with /p/{id})
   • Category: /Category-Name-c12345 (clean URL with -c{id}) or #!/category/Category-Name/cid/12345 (hash URL with /cid/{id})
2. Ensure the product/category exists. If the destination product has been deleted, the redirect will fail silently.
3. Use debug mode. Add ?srm_debug=1 to the URL and check the browser console for [SRM] messages. Note: on Wix, debug messages may appear in the Ecwid iframe's console — you may need to select the correct iframe context in your browser's developer tools.
4. Hard refresh. Press Ctrl+Shift+R (Cmd+Shift+R on Mac) to clear cached scripts.

Note about 404 detection on Wix: 404 detection is not available on Wix due to false positives in the Ecwid iframe. This is expected behavior — the admin UI hides 404 detection features automatically on Wix stores.

404 Detection Not Working on Instant Site

The 404 Errors page is hidden or shows a message about embedded stores.

This is expected. 404 detection requires the app's storefront JavaScript to run, which only works reliably on embedded stores (WordPress, Wix, Squarespace, custom sites). On Ecwid Instant Site, the server may return a static 404 page that doesn't load app scripts. The admin UI automatically detects your platform and hides 404 features for Instant Site stores.

If you believe your store is incorrectly detected as Instant Site, contact support.

Redirects Not Executing on Instant Site

Redirect rules are created but visitors are not being redirected on Instant Site.

Client-side redirect execution is unreliable on Instant Site because Ecwid controls the server and may resolve or reject URLs before the app's JavaScript loads. The redirect rules are still stored and visible in the dashboard, and webhook-based deletion detection still works.

The redirect management dashboard and automatic deletion detection remain useful for keeping a record of URL changes even on Instant Site.

Auto-Redirects Not Being Created

You deleted a product but no auto-redirect appeared.

1. Check Settings. Open the Settings page from the sidebar and confirm Automatic Redirects is enabled.
2. Ensure the product was fully deleted. Disabling or hiding a product does not trigger an auto-redirect — only permanent deletion does.
3. Check that the product URL was recorded. Auto-redirects require the app to know the deleted product's URL. If the product was created before the app was installed and the initial catalog sync was incomplete, the URL may not be on record. Try running a manual sync from the Settings page.