SEOnaut tutorial: run your first crawl and verify the fixes

Start your first SEOnaut crawl with a small site whose errors you already know. Confirm that the crawler finds a broken destination, a redirect, and a repeated title, then repair those cases and crawl again. This gives you evidence that the workflow can detect and verify specific changes before you trust a large report.

SearchEngineAnswer ran that sequence on October 25 using SEOnaut’s actual crawler services and database against an isolated local fixture. The first pass visited five URLs; the second visited three after the root page stopped linking to the missing and redirected addresses. This was a crawler-service test, not a test of the hosted dashboard or Docker installation.

Choose hosted or self-hosted before adding a project

The maintainer’s support page offers a hosted route and a self-hosted community version. At the time of this review, its hosted free plan lists one project and up to 500 URLs. Hosting limits are separate from the open-source software license and can change.

For self-hosting, use the official repository and follow its Docker Compose instructions. Those instructions provision the application and a database. Review the supplied configuration, replace example credentials, and keep a local evaluation private. Pin a reviewed source revision rather than assuming that a later latest image reproduces the same behavior.

The local experiment used source commit a67387fe63a291be2ba49dd02399f20e453eb8b5Go 1.27.3 and a separate MySQL 8.4 database. It invoked the application’s project and crawler services directly. This identifies the tested code and makes the deployment boundary explicit; it does not validate every UI route.

Define three known cases before the first crawl

Use a test site you control. The fixture in this demonstration linked to two pages with the same title, an address returning 404, and an old address redirecting (301) to a valid page. The remaining markup was deliberately minimal, so the crawler could also report unrelated warnings.

The redirect remained a valid redirect. Removing the internal reference made the crawl route more direct; it did not prove that every redirect is harmful. Likewise, this small link graph no longer discovered the missing page. Other sources, such as a sitemap or external link, could still lead a crawler to it.

Keep the first project bounded

1. In the hosted workflow, add the test website and review its crawl settings before starting. In a self-hosted setup, confirm that the application can reach the intended origin.
2. Keep subdomains, external links, and sitemap discovery outside the first fixture unless they are part of the question. Record which options you enable.
3. Save the first findings and the requested URL for each one. Confirm the HTTP response or page markup independently.
4. Repair one known problem at a time, rerun the same scope, and compare the exact finding rather than the overall warning total.

The second local pass still reported issues such as repeated descriptions and missing viewport or security headers. Those remaining findings are expected in this deliberately minimal HTTP fixture. The test does not support a claim that the site became error-free, that every severity label represents lost traffic, or that fixing these cases increased rankings.

Preserve the evidence you need for a real audit

Download the observed two-pass fixture findings (CSV)

The CSV contains the phase, local path, response status, and issue identifier. It is an actual test record, not a sample production audit. Do not use the fixture’s warning totals as a benchmark for another website.

Use the GitHub SEO repository catalog to compare tools by task. For a launch, combine the crawl with the technical SEO release sequence: a crawler report cannot replace canonical, measurement, and rollback checks.