WIZEHAWK DOCUMENTATION
Store Discovery Audit — Complete Setup & Support Guide
Install the plugin, understand your first scan, fix the right problems, and verify the result. Practical instructions for Free and Pro, with clear limits on what the checks can prove.
In this guide
- Before you begin
- 1. Install and run your first scan
- 2. Read results without overreacting
- 3. Check discovery and crawler access
- 4. Improve product data and structured data
- 5. Run a live-page deep test
- 6. Use Pro bulk fixes carefully
- 7. Understand AI activity
- 8. Configure Pro monitoring and alerts
- Free and Pro at a glance
- Troubleshooting checklist
- Updates and stored data
- Get useful support
Before you begin
This guide covers Store Discovery Audit 0.18.3. The plugin is in public-release preparation; a guide is not an announcement that the WordPress.org download or Pro purchase is available. See the product page for release status.
- WordPress 6.5 or newer and PHP 8.0 or newer.
- WooCommerce installed and active for product scanning. The admin screen can open without it, but that does not create a product catalog.
- Administrator access and at least one published product to inspect.
- A public, reachable store URL for public crawler verification and live-page tests. Local development sites support local checks only.
The scanner does not require an OpenAI API key or WizeHawk cloud account. Optional Pro email alerts use a hosted service; licensing uses Freemius. Those connections are separate from the local scanner.
Practical troubleshooting: Why Your WooCommerce Products Aren’t Showing in AI Shopping Results · How to Find and Fix Missing or Duplicate WooCommerce Product Schema
1. Install and run your first scan
- When you have an official plugin ZIP, open WordPress Plugins → Add New Plugin → Upload Plugin, upload it, install, and activate. Back up before replacing an existing version.
- Open Store Discovery Audit in WordPress admin. Confirm WooCommerce is active before diagnosing missing products.
- Click Run store scan and allow the scan to finish. Repeated clicks do not make it faster.
- Start on Overview. Read What to work on next, then follow each finding to Discovery or Products.
- Record the first result as your baseline. Make a focused change, rerun the scan, and confirm the relevant finding changed.
The main tabs are Overview, Discovery, Products, AI activity, History, and Settings. The regular scan and per-product live-page test serve different purposes; a completed store scan does not mean every public product page has been deep-tested.
2. Read results without overreacting
Resolve blocking access and schema issues first, then warnings and incomplete product information. Read the evidence attached to a finding before editing anything.
- Ready: the specific check passed. It does not promise inclusion in an AI answer or shopping result.
- Attention / Warning: review the information and the suggested improvement.
- Issue / Blocking: investigate the failure before relying on dependent checks.
- Not provided: optional data such as brand or GTIN may be absent. Do not invent identifiers to turn a row green.
- Blocked by schema issue: fix the missing or invalid Product schema first, then retest dependent fields.
Readiness scores summarize technical checks. AI activity is deliberately separate: a quiet store is not automatically misconfigured, and a high score cannot guarantee crawling, citations, recommendations, rankings, or sales.
3. Check discovery and crawler access
- Open Discovery and review WordPress search visibility, robots.txt, sitemap findings, and the individual crawler rules.
- If a public store is unintentionally discouraged from indexing, review Settings → Reading. Keep private staging sites private.
- For a blocked crawler, identify the exact robots rule or server response. Check the SEO plugin, physical robots.txt file, security plugin, CDN, or hosting controls responsible for it.
- Check that the reported sitemap and product URLs load for a signed-out visitor. Fix redirects, authentication barriers, and unavailable pages at their source.
- Rerun the scan after changing access settings. Clear relevant page/CDN caches if stale responses remain.
Robots permission and a verified crawler visit are different facts. Allowing a crawler does not make it visit, and a policy result does not prove that a firewall permits the request. Local sites cannot provide a reliable public-access test.
For more background, read how to check AI crawler access for WooCommerce.
4. Improve product data and structured data
Open Products, choose an affected product, and compare the finding with the actual WooCommerce product. Keep titles, descriptions, images, prices, currency, stock status, and identifiers accurate. Check variations individually where the finding requires it.
The scanner inspects WooCommerce Product JSON-LD, including offers, price, currency, availability, image, SKU, and optional identifiers. If several schema fields fail together, diagnose the schema producer or conflicting theme/SEO plugin before editing every product.
- Use an existing genuine SKU or identifier where your business already has one. Never invent GTINs, brands, or manufacturer information.
- Write useful descriptions grounded in the real product; remove unsupported claims.
- Confirm that the customer-facing price and availability agree with WooCommerce.
- Use the finding’s edit link to correct the relevant product or setting, save it, then scan again.
See preparing WooCommerce product data for AI shopping for the underlying content checklist.
5. Run a live-page deep test
- On a public store, find the affected product and click Test live page.
- Review the fetched page’s indexability, canonical URL, final Product JSON-LD, and any duplicate schema findings.
- Compare the public product URL with the expected product. Resolve redirects, cache differences, access challenges, or competing schema output.
- After a correction, use Test again. A previous result is a snapshot, not continuous proof that the page is healthy.
Live tests are separate from the fast store scan so large catalogs do not trigger a full public-page fetch for every product each time. They are unavailable on local sites. The test inspects the response it can retrieve; do not treat it as proof that every external crawler or JavaScript-based storefront will see identical output.
6. Use Pro bulk fixes carefully
Pro offers Generate missing SKUs and Apply short-description drafts. Back up product data and review a small selection first.
- Select eligible products in the bulk-fix table. Products that cannot be safely fixed may be unavailable for selection.
- SKU generation applies to products without a SKU. Check compatibility with any stock or fulfillment system before generating business identifiers.
- Short-description drafts use the product’s existing full description and do not overwrite an existing short description.
- If the full description is too thin, open Edit product and write the missing information manually. The tool cannot safely create facts that are not there.
- Review the saved product and refreshed scan results after applying a fix.
7. Understand AI activity
AI activity records recognized crawler requests and AI referral visits that reach WordPress. Crawler names and verification status must be read together: a matching user-agent alone is not proof of identity. Where supported, verification uses published provider IP ranges. Visitor IP addresses are not stored in the activity table.
Free provides basic seven-day counts. Pro adds advanced reporting, longer period views, and top AI-accessed products. Activity records have a 90-day cleanup policy; this is not an unlimited analytics archive.
Use Test monitoring to check the reporting path. Test rows are labeled and can affect displayed totals; use Clear test activity when finished. Test activity is not evidence of a real AI visit.
No activity may simply mean no recognized request arrived. Logged-in administrators are excluded, and requests served entirely by a cache or CDN may never reach WordPress. This monitor cannot reconstruct visits from before it was installed or prove that an AI system recommended your product.
8. Configure Pro monitoring and alerts
Free keeps the three most recent scan summaries. Pro adds full history views, scan comparisons, regression monitoring, and automatic daily scans. In Settings, use Enable automatic scans or Pause automatic scans and check the next scheduled time and last attempt.
WordPress cron runs when the site receives traffic, so the displayed time is not a guaranteed delivery deadline. If scans stop, first confirm Pro access, the enabled setting, and WordPress scheduled-task health. Manual scans remain available.
- For Pro email alerts, enter the destination address in Settings and click Save alert email. Saving a valid address enables alerts.
- Click Send test alert, then check the actual inbox and Spam folder. A saved address alone does not verify delivery.
- Read the displayed delivery result. If the hosted service is unreachable or rejects the request, copy the exact error for support. Changing your site’s SMTP settings does not repair this separate hosted delivery route.
- Use Turn off to disable email alerts while retaining dashboard monitoring.
Release limitation: hosted alert delivery is available in Pro. Use Send test alert after setup to confirm delivery to the address you entered. Regression emails concern new deteriorations between scans, not a daily message repeating every existing warning.
Free and Pro at a glance
- Free: manual store audit, product checks, live-page testing, basic seven-day AI activity counts, and three recent scan summaries.
- Pro: automatic daily scans, regression monitoring, hosted email-alert controls, full history and comparisons, bulk fixes, advanced activity reporting, and top AI-accessed products.
- Support: Free includes documentation and best-effort email help with no guaranteed response time. Pro receives priority help for installation, configuration, and troubleshooting.
Free is available from WordPress.org. Pro is available as a separate licensed add-on and works alongside the Free plugin.
Troubleshooting checklist
- No products: confirm WooCommerce is active and the expected products are published; rerun the scan.
- Old warning remains: save the source change, clear relevant caches, then rerun the appropriate store scan or individual live test.
- Live test unavailable: check whether this is a local/private URL. Do not make staging public simply to obtain a green result.
- Several schema fields fail: resolve the parent schema issue or duplicate output before rewriting all product data.
- Bulk fix unavailable: check Pro access and whether the product actually meets the safe-fix conditions.
- No scheduled scan: check the enabled setting, license state, next-run display, and WordPress cron.
- No alert email: send one test, check the service result and mailbox, and report the exact error. A scan without new regressions need not send an email.
- Zero activity: test monitoring and distinguish sample data from real traffic. Check whether requests reach WordPress.
Updates and stored data
Back up before updating. After an update, open the dashboard, run a manual scan, and test one representative public product. Recheck automatic-scan and alert settings if you use Pro. Freemius handles licensing-related connections; no OpenAI key is needed for the scanner.
Scan history and AI activity are stored on the site. In the checked 0.18.3 package, those tables are intentionally preserved during uninstall. Deleting the plugin is therefore not a complete data-erasure procedure. Contact support if you need to remove retained data; do not delete database tables by guessing their names.
Optional hosted alerts send the recipient, site identity, and alert content to WizeHawk for delivery. This is separate from the locally stored scan history.
Get useful support
Send the plugin version, Free/Pro plan, WordPress/PHP/WooCommerce versions, affected public product URL, exact finding or error, steps taken, and what you expected. A cropped screenshot of the relevant result helps. Remove private customer information and never send passwords, API keys, or license keys.
Billing, licensing disputes, security incidents, privacy requests, possible data loss, and reproducible defects need a human review. Do not disable site security or change database records just to clear a warning.
Contact WizeHawk support · Store Discovery Audit product page · All documentation
Checked against plugin package 0.18.3. Updated September 21, 2026.