Troubleshooting

Most likely it is queued, not stuck. Scans currently run one at a time across the platform, so during busy periods your scan waits before it starts. The queue position is not shown yet.

A scan that has genuinely stalled is detected and cleared automatically after a timeout. Escalate if it has been over an hour with no progress, or if the same scan has been cleared twice.

Check, in order:

1. Your site is reachable from the public internet
2. It is not behind a login wall, IP allowlist or aggressive bot protection
3. robots.txt is not blocking our crawler
4. Your domain in Crawlix matches the form your site actually serves

• robots.txt is blocking the crawler. Crawlix obeys it, including rules targeting our crawler specifically
• Pages are not linked internally. The crawler follows links, so orphan pages are not discoverable — which is itself a finding, since they do not rank well either
• Content requires JavaScript and the page under-renders
• A crawl limit on your plan

Tell us. A false positive is a bug, not a difference of opinion. Include the exact URL, the issue type, and what you see in view-source.

Common legitimate confusions:

• The issue is on a URL that redirects — check the exact URL reported
• The page changed after the scan ran
• The content is injected by JavaScript and is not in the origin HTML — which is itself the problem, because crawlers that do not run JavaScript see what Crawlix saw

The score is issues weighted by severity, so a change should always be explainable by the issue delta.

• Score dropped with no new issues → possibly new pages were discovered, each with their own issues
• Score moved with no issue change → that is a bug. Please report it

1. Confirm it is on the page — view source and search for the script tag
2. Confirm it is on the page you are testing, not only the homepage
3. Check your Content Security Policy. A script-src that does not allow our host blocks it silently — your browser console will show the error
4. Purge your CDN or page cache
5. Real visitors must load the page. Field Core Web Vitals need actual traffic, and no traffic looks identical to a broken install

Reconnect rather than editing credentials. Stored credentials are encrypted, and a partial update fails in confusing ways.

Usually transient — retry. Persistent failures normally mean the AI provider is unreachable or not configured on your plan. Crawlix reports that rather than inventing a suggestion.

Check which method it tried:

Check where the fix was delivered. This is the most common confusion in the product, and the distinction is real:

• CMS or merged pull request — the change is in your origin HTML. A re-scan should clear the issue
• Edge — the change is in the response Crawlix proxies, not at your origin. Anyone fetching your site directly sees the original
• Snippet — the change happens in the visitor's browser. A crawler that does not run JavaScript sees the page unchanged

Use curl to see what a crawler sees. See reviewing and applying fixes.

• Rank tracking and competitors need a rank-data provider on your plan. Without one every figure is null and the interface says so, rather than estimating
• AI visibility shows "not configured" unless citation checking is enabled — which means we did not check, not that no citations exist
• Search Console data can take 48 hours, and the property must match your project domain exactly
• Field Core Web Vitals need the snippet installed and real traffic

Open a support ticket from the Help page inside your dashboard. Include your project ID, the URL involved, what you expected, what happened, and roughly when.