Troubleshooting

Vexifa's crawler sends a hardcoded user agent: Mozilla/5.0 (compatible; VexifaSEO/1.0; +https://vexifa.com). There is no Settings option to change this — it's the same identifier on every Vexifa install so site owners can allow or deny it deliberately.

A. Confirm the block. Open the robots.txt tester (the only place that accepts a custom user-agent string) and test the URL against VexifaSEO. If robots.txt is disallowing you, the site has chosen to block the crawler — your only option is to ask the owner to allow it, or to use JS Rendering instead.

B. Enable JS Rendering. On the crawl form, tick JS Rendering (slow — ~2-4s/page). Headless mode drives a real browser (Edge or Chrome), so requests carry a browser user agent and usually bypass bot-blocking firewalls and WAFs.

C. Slow it down. On the crawl form, raise the Politeness Delay slider — some sites only block when request frequency crosses a threshold.

Vexifa SEO is free with a 60-day grace period after install. Once the grace ends, this reminder appears on each launch — wait the 5 seconds, click Continue, and the dialog goes away until next launch. Every feature in the app remains fully functional — audits, crawls, drift baselines, history, API keys, rank tracking, everything. Nothing is gated behind the splash.

If you want to remove the reminder entirely, subscribe to the optional support sub via PayPal at $19/yr. You're paying for ongoing development, not access — the feature set is identical either way.

1. Ensure the Ollama application is running in your system tray.
2. If not, run ollama serve in a terminal to start the engine manually.
3. Verify you've pulled the default model: ollama pull llama3.2.
4. In Vexifa, open Settings → Provider → Ollama and confirm the Base URL is http://localhost:11434.

The simplest fix: install from the Microsoft Store. Vexifa SEO is distributed as a signed MSIX package via the Store — installing from there avoids SmartScreen entirely because the package is signed and store-verified.

If you've sideloaded the .exe directly, the Unknown Publisher dialog is expected. To run it:

• ✓ Click "More Info" in the blue alert box.
• ✓ Click "Run Anyway".

Rank tracking requires a third-party SERP API key to bypass Google's bot detection. Vexifa supports two providers — add either (or both) in Settings → Integrations:

• SerpAPI — 100 free searches/month at serpapi.com. Plenty for tracking a small keyword list weekly.
• DataForSEO — pay-per-call at roughly $0.0006/search. Cheaper at scale.

If you have both keys set, Vexifa uses DataForSEO first. If a single keyword is failing while others succeed, you've probably exhausted the SerpAPI free quota for the month — check your provider dashboard.

By default, Vexifa's crawler is a fast HTTP fetcher — it reads the raw HTML response and does not execute JavaScript. To capture JS-rendered content, enable headless browser mode on the crawl form:

1. Open the Crawler tab.
2. On the crawl form, tick the checkbox labelled JS Rendering (slow — ~2-4s/page).
3. Re-run the crawl.

There is no Rendering Mode submenu and no separate Wait Time field — it's a single checkbox. Vexifa handles wait-for-network-idle internally per page.

Vexifa uses a local OAuth loopback redirect (http://127.0.0.1:{port}/oauth/callback) to receive the authorization token. This process can be blocked by browser security or antivirus.

1. Ensure no browser extension (especially ad-blockers and privacy extensions) is blocking redirects to localhost or 127.0.0.1.
2. If your default browser is a hardened profile, try the OAuth flow in an incognito/private window or a different browser.
3. Temporarily disable any firewall rule that blocks inbound connections to local ports.

Once you authorize the app in Google, the loopback handler captures the token automatically — you don't need to click anything else in Vexifa. The same OAuth session is reused for Google Analytics 4 if you add a GA4 property ID later.

Vexifa's scheduler is in-app only. Schedules are stored in a local crawl_schedules.json file inside the app data directory, and the scheduler polls next_run_at at launch and periodically while the app is open.

It does NOT register a Windows Task Scheduler job. There is no VexifaSEO_CrawlSchedule task — looking for one in the Task Scheduler Library will turn up nothing, by design.

By far the most common reason a scheduled crawl didn't fire: Vexifa wasn't running at the scheduled time. To fix it:

• Leave Vexifa running in the background on the machine where the schedule lives.
• Or open Vexifa before the next scheduled trigger time — when it launches, the scheduler checks next_run_at for every schedule and runs anything that's due.
• Daily schedules are the most reliable if you only open the app sporadically; weekly/monthly are best for an always-on workstation.

A short crawl almost always comes down to one of a handful of causes. Work through them in order:

1. robots.txt is disallowing VexifaSEO. Open the robots.txt tester and check the start URL against the user agent VexifaSEO. If it's blocked, the rest of the crawl can't proceed.
2. No sitemap and no discoverable links. If the start URL is a SPA shell with no <a> tags in the raw HTML, the crawler has nothing to follow. Enable JS Rendering on the crawl form and try again.
3. JavaScript-rendered links. Same fix — enable JS Rendering so a real browser can discover client-side links.
4. Limits set too low. Check Max Pages and Max Depth on the crawl form. Default Max Depth caps how deep into the site structure the crawler will descend.
5. Redirect loops. If every URL bounces between two paths, the crawler stops. Open the crawl in Crawl History and look at the status codes — a row of 301s pointing in a circle is the giveaway.
6. Wrong protocol or subdomain. Crawling http://example.com when the site redirects to https://www.example.com can produce a short crawl if the canonical host filter rejects the redirect target.

Structured data errors mean your JSON-LD is present but invalid per schema.org. This prevents Google from displaying rich results for those pages.

1. Click the flagged page in the audit results to see the specific property causing the error.
2. Copy the page URL and paste it into Google's Rich Results Test (search.google.com/test/rich-results) for a side-by-side error breakdown.
3. Common fixes: add a missing @type, ensure datePublished is in ISO 8601 format (YYYY-MM-DD), and verify all required properties for your schema type are present.
4. Re-run the Schema Markup skill on the page after the fix to confirm the error has cleared.

Hreflang requires reciprocal tags — every page that declares a language alternate must be referenced back by the alternate page. A one-way reference is treated as invalid by Google.

To fix: Ensure that if /en/ declares <link rel="alternate" hreflang="fr" href="/fr/">, then /fr/ must declare <link rel="alternate" hreflang="en" href="/en/"> in return. Every page in the cluster must also reference itself with its own language code.

After fixing, re-crawl and re-run the audit. The hreflang checker re-validates all pairs from scratch on each audit run.

Content Freshness is one of Vexifa's 23 audit skills — you select it per-audit run from the skill dropdown in the Audit tab. It's not a background scanner with a settings panel, and there's no "Freshness Threshold" to tune. It evaluates the page's dateModified and datePublished in JSON-LD, the HTTP Last-Modified header, and sitemap lastmod signals.

False stale (recently updated page flagged as old): Your pages almost certainly lack a dateModified property in their JSON-LD schema, so the skill is falling back to weaker signals. Add an Article or WebPage schema with accurate datePublished and dateModified fields.

False fresh (outdated page not flagged): The Last-Modified header may reflect a CDN cache refresh rather than an actual content change. Adding explicit dateModified schema is the authoritative fix here too.