Screaming Frog vs Audra: Website Migration Audit Workflow

A single legacy URL can expose a migration failure: /old-service/ may return a 404, or take users through a 301 and 302 before reaching an irrelevant page. This Screaming Frog site migration audit guide gives teams a concrete before, during, and after workflow for checking old URLs, redirect paths, new-site SEO signals, and broader launch quality.

Screaming Frog SEO Spider and Audra solve different parts of the migration problem. SEO Spider is the more established specialist workflow for crawling URL inventories, uploading old URLs in List mode, and tracing redirects. Audra is a local desktop audit app for macOS and Windows that combines AI answer-engine visibility, technical SEO, performance, accessibility, best-practice, and link checks in a report-oriented audit. For many migrations, the useful comparison is not replacement versus replacement; it is which evidence each tool provides at each stage.

What a website migration audit must prove

A website migration can mean a domain change, CMS rebuild, redesign, HTTPS move, URL restructure, content consolidation, or a subdomain-to-subfolder move. Lumar and Moz both frame migration as a phased process rather than a launch-day check, because search visibility can be affected before code reaches production and for weeks afterward.

The audit should establish four specific outcomes:

• A saved baseline exists for the current live site, including important URLs and their technical signals.
• Every old URL has an intentional outcome: retained, redirected to a relevant replacement, or deliberately removed.
• The new build exposes the pages that should be discoverable and does not introduce accidental technical barriers.
• A post-launch review distinguishes planned reductions from unexpected losses.

For example, a content consolidation may reduce 1,200 old URLs to 780 new URLs. That reduction is not inherently bad. It becomes a problem when the 420 missing URLs include high-value category pages, linked resources, or organic landing pages with no documented destination. A page-count difference is evidence to investigate, not a pass or fail result on its own.

Screaming Frog’s migration guidance provides the core sequence: crawl the existing site, assess the staging site, test redirects, and validate the live result. The practical addition is to assign each task to a decision: preserve, redirect, remove, repair, or monitor.

Screaming Frog site migration audit: capture the baseline

Before changing templates, navigation, or URL patterns, crawl the live site and save the crawl data. The baseline answers questions that otherwise become difficult after launch: Did this page exist? Was it indexable? What title, canonical, and internal-link context did it have? Was a missing page a planned retirement or an accidental omission?

Build the URL inventory from more than one source

A crawl from the homepage is useful, but it may not find every URL worth protecting. Screaming Frog’s site-migration material recommends combining crawl data with XML sitemaps and data sources such as Google Analytics and Google Search Console. Moz or another link-data provider can help identify pages with external links that should receive special redirect attention.

A practical baseline export includes:

• Internal URLs, status codes, canonicals, titles, meta descriptions, headings, directives, and inlinks.
• URLs from the XML sitemap, including older sitemap files where they remain available.
• High-priority organic landing pages from analytics and Search Console.
• Externally linked pages identified through Moz or another backlink source.
• Important resource types such as PDFs, product pages, campaign pages, paginated URLs, and regional variants.

The priority list matters because not all URLs carry the same migration risk. A discontinued campaign page with no traffic may have a valid removal path, while a service page with historic backlinks needs a documented decision. Teams can use an audit plan that prioritizes fixes to separate launch blockers from lower-impact cleanup work.

Audra can provide a complementary baseline when the project also needs an initial record of technical SEO, performance, accessibility, links, best practices, and AI answer-engine visibility. That wider record helps prevent a common handover dispute: attributing a pre-existing issue to the migration without evidence of its prior state.

Crawl the staging build before launch

The staging crawl should happen when the new build is sufficiently complete to represent production behavior. Compare the staging output against the live baseline, focusing on page coverage, titles, canonicals, robots directives, internal links, XML sitemap contents, and key page templates.

Screaming Frog’s documentation specifically covers crawling staging environments. A staging setup may have authentication, IP restrictions, robots controls, or noindex directives. Those protections can be appropriate before launch. The audit task is to document them and make sure they are not accidentally carried into production.

Consider an example where the old crawl contains 1,200 indexable URLs and the staging crawl contains 780. The team should classify the difference:

1. Expected removals: thin archives or retired products with approved removal decisions.
2. Expected replacements: old URLs that map to a relevant new destination.
3. Unexpected omissions: pages missing from staging without a redirect or retirement rationale.
4. Crawl-access differences: pages excluded because staging access or directives differ from production.

Screaming Frog documents JavaScript rendering and staging crawling as available workflow areas, which can matter where important navigation or content is rendered client-side. The exact configuration and interpretation still depend on the site’s architecture; a rendered crawl does not by itself prove that every user or search engine will receive the intended content.

Audra is best positioned here as a broader audit of a site that is accessible to the auditor. Its stated checks can identify whether the build has technical SEO, performance, accessibility, link, or best-practice issues beyond URL mapping. It should not be assumed to replace SEO Spider’s staging configuration or old-URL List mode process without confirming the project’s requirements.

Upload and crawl old URLs in List mode

After launch, the first redirect test should start with the old URL inventory, not solely with a crawl from the new homepage. A homepage-led crawl discovers the new architecture; it does not reliably test URLs still requested through old bookmarks, backlinks, browser history, XML sitemaps, or search results.

In Screaming Frog SEO Spider, switch to List mode, upload or paste the legacy URL list, and crawl it against the live environment. Screaming Frog’s redirect-audit tutorial describes this workflow for checking uploaded URLs and their redirect behavior.

The upload list can combine URLs from the pre-migration crawl, sitemaps, analytics, Search Console, server logs, historic redirect files, and Moz backlink data. Deduplicate where practical, but do not remove useful variants merely because they are not linked in the new navigation. Include HTTP and HTTPS patterns where relevant, www and non-www variants, trailing-slash variations, legacy PDFs, and discontinued pages that still have external references.

A redirect map should capture intended and actual behavior separately:

This approach makes the migration testable. A spreadsheet may say a redirect exists, but the List mode crawl records what the server actually returns at the time of the audit.

Find redirect chains and confirm final targets

Enable Always Follow Redirects before crawling the uploaded old URLs. This lets SEO Spider follow the route beyond the first response, helping reviewers identify redirect chains, loops, and the final target URL. Screaming Frog’s redirect-audit tutorial specifically recommends this approach for tracing redirect paths.

A redirect review should ask five questions:

1. Does the old URL produce the intended response?
2. Does the path reach the planned final URL?
3. Is the final destination relevant to the old page’s purpose?
4. Is there an avoidable chain, loop, or temporary step?
5. Does the final page have the intended technical treatment for its role?

The final question needs context. A final target does not universally need to return a 200 response and be indexable. A deliberately retired page may correctly return 404 or 410. A login page, confirmation page, filtered result, or other controlled destination may appropriately be non-indexable. For an old indexable service page mapped to a replacement service page, however, a direct, relevant, intended-to-index destination is commonly the desired outcome.

For instance, /blog/seo-audit-2024/ might go to /blog/seo-audit/, then to /resources/seo-audits/. The browser may eventually show a page, but the chain adds an unnecessary hop and obscures the actual redirect rule. Where the final destination is approved, the original rule can usually point directly to it.

Audra should be treated cautiously in this part of the workflow. Its stated audit scope can help assess the quality of final pages, but the provided product description does not establish a specialised equivalent to SEO Spider List mode with Always Follow Redirects. For a large redirect inventory, SEO Spider is the more clearly documented choice.

Validate the new site beyond redirects

A redirect can be correct while its destination is technically weak. A replacement page may have a canonical pointing elsewhere, an accidental production noindex, broken internal links, poor performance, inaccessible components, or content that no longer answers the query the old page served.

The post-launch audit should include concrete checks across at least five areas:

• Crawlability and indexation: review robots rules, meta robots, canonicals, and any staging references left in production.
• XML sitemap: include canonical URLs intended for indexing, rather than obsolete paths or redirected URLs.
• Internal links: find broken links and old URLs still used in navigation, breadcrumbs, templates, or content.
• Template quality: compare home, category, product, service, and article templates instead of testing one representative page.
• User-facing quality: review performance and accessibility findings introduced by new components such as menus, forms, images, and modal dialogs.

Screaming Frog’s product and migration materials support crawl-based investigation, URL exports, JavaScript rendering, crawl storage, selected integrations, and redirect auditing. Those capabilities make it suitable for detailed URL and technical inspection. The supplied material does not establish that it should be considered universally stronger for every accessibility or performance use case, so teams should validate the checks and data they need in their own configuration.

Audra’s stated scope is broader at the report level: technical SEO, performance, accessibility, best practices, link audits, and AI answer-engine visibility. This can be useful where a migration changes both architecture and presentation. A launch report can show that redirect mapping passed while a new template introduced broken links or accessibility issues.

When a redesign also rewrites important editorial pages, the content review should not stop at response codes. The related article on ChatGPT-rewritten content versus expert writing offers a useful adjacent consideration: pages should retain specific, supportable information rather than becoming thinner after the move. That is especially relevant where the team wants content to remain useful in both conventional search and answer-engine results.

A concise website migration checklist for SEO

Lumar’s migration checklist and Moz’s migration guide both support a phased structure. The following checklist keeps that structure tied to evidence rather than generic launch QA.

Before launch

• Crawl and save the current live site in SEO Spider.
• Export internal URLs and add XML sitemap, analytics, Search Console, log, and Moz-derived priority URLs where available.
• Classify each valuable old URL as retain, redirect, or intentionally remove.
• Create and review the redirect map, including an intended final destination.
• Crawl the staging build and compare page coverage, metadata, canonicals, directives, internal links, and templates.
• Prepare production robots rules and an XML sitemap that reflects intended canonical URLs.

Launch day

• Deploy and test redirect rules alongside the new URL structure.
• Upload the old URL list in Screaming Frog List mode.
• Enable Always Follow Redirects and identify loops, chains, wrong targets, 404s, and unintended temporary redirects.
• Check priority templates manually, including navigation and conversion paths.
• Run a wider site audit to identify technical SEO, performance, accessibility, link, and best-practice regressions.

After launch

• Re-crawl the new site and compare it with the saved baseline.
• Monitor Search Console for indexing, coverage, sitemap, and crawl anomalies.
• Track high-value landing pages, traffic, conversions, and rankings separately from broad site averages.
• Re-test redirects after CMS releases, CDN changes, or redirect-rule hotfixes.

The checklist should change with the migration type. A same-path domain move may focus heavily on host and protocol redirects, while a CMS rebuild with a 60% URL reduction requires more detailed retirement decisions and content mapping.

Reporting: diagnostic data versus decision evidence

SEO Spider’s strength is the level of URL-level evidence an experienced practitioner can inspect: exports, response codes, inlinks, crawl data, and redirect paths. Screaming Frog also documents crawl storage and selected integrations, which can support repeatable technical investigation across a project.

That depth can be harder to present to a non-technical client. A development team may need the exact old URL, response path, final target, and rule to fix. A stakeholder typically needs a shorter decision view: launch blockers, priority, owner, deadline, and residual risk.

Audra fits the latter reporting need because it is positioned around local desktop auditing and client-ready reports across its stated categories. It can give agencies and consultants a single artifact covering technical SEO, performance, accessibility, best practices, links, and AI answer-engine visibility, while the redirect spreadsheet and SEO Spider exports remain the technical proof.

A useful two-layer deliverable is:

• Technical evidence: legacy URL list, redirect map, SEO Spider exports, chain examples, crawl comparisons, and developer tickets.
• Stakeholder summary: issues by severity, completed fixes, remaining decisions, key template findings, and a dated post-launch monitoring plan.

The pricing and exact feature limits of either product should be checked on the respective vendor pages at the point of purchase or project planning. This comparison avoids fixed price claims because commercial terms and product limits can change.

Which should you choose?

Choose Screaming Frog SEO Spider when the dominant risk is URL-level complexity. It is the clearly documented option for crawling old URLs in List mode, using Always Follow Redirects, finding chains and loops, exporting URL data, crawling staging environments, and investigating a redirect map in detail. It is especially appropriate for domain changes, large URL restructures, and migrations with many legacy paths.

Choose Audra when the team needs a broader audit view and a report that combines the stated technical SEO, performance, accessibility, best-practice, link, and AI answer-engine visibility checks. It suits consultants, agencies, marketers, and site owners who need a local desktop audit and client-facing evidence alongside migration decisions.

Choose both when a project changes URLs, templates, content, and site quality at the same time. Use SEO Spider for the old-URL inventory and redirect-path validation. Use Audra to assess the broader health of the accessible new site and communicate findings beyond redirects. This combination is practical for ecommerce replatforming, redesigns with content consolidation, and multi-template CMS migrations.

Verdict

For redirect-heavy work, SEO Spider is the more directly documented migration tool: List mode and Always Follow Redirects offer a repeatable way to test old URLs and identify their final destinations. That workflow is difficult to replace with a general site audit alone.

Audra adds value where migration assurance must extend beyond redirects into technical SEO, performance, accessibility, links, best practices, and AI answer-engine visibility. The strongest process preserves detailed redirect evidence while also documenting whether the new site is healthy enough to support users, search engines, and client handover.

FAQ

How do you use Screaming Frog SEO Spider before and after a site migration?

Before launch, crawl and save the live site, then export internal URLs and add priority URLs from XML sitemaps, analytics, Search Console, logs, and backlink sources such as Moz. Crawl staging for comparison. After launch, crawl the new site and test the legacy URL list in List mode to identify redirects, chains, final destinations, and errors.

How do you upload and crawl old URLs in List mode?

Export the old URL inventory from the baseline crawl and supplement it with sitemap, analytics, Search Console, server-log, and backlink URLs. In SEO Spider, select List mode, upload or paste the URLs, and start the crawl. This tests known legacy requests directly rather than discovering only URLs linked from the new homepage.

How do you find redirect chains and confirm the final target URL?

Enable Always Follow Redirects before running the List mode crawl. Review the response path, final destination, and whether the final result matches the planned outcome. Investigate loops, unnecessary multi-hop paths, temporary redirects used by mistake, and irrelevant destinations. A 200 indexable final page is appropriate for many replacement pages, but intentional removals and controlled pages can have valid different outcomes.

How can a site migration be completed without losing SEO?

No process guarantees zero visibility fluctuation, particularly when domains, content, templates, and architecture change together. Risk is reduced by saving a baseline, mapping valuable old URLs to relevant replacements, auditing staging, testing redirects at launch, maintaining correct canonical and indexation signals, publishing an accurate XML sitemap, and monitoring Search Console plus high-value landing-page performance after release.

Is Screaming Frog SEO Spider safe to use for a site migration audit?

SEO Spider makes crawl requests to the target environment, so it should be used with development-team coordination and sensible crawl settings. Confirm how staging access, authentication, robots controls, and infrastructure capacity are handled before a large crawl. Its documented staging-crawl workflow is useful, but teams remain responsible for permissions, timing, and avoiding unnecessary load on sensitive environments.