Launch QA report

Run a report

Open the link settings and click Run QA report in the Launch QA section (it uses the link’s run settings). The crawl starts at the home page and follows links on your domain. It usually takes a few minutes and you can close the panel meanwhile. A crawl that has not finished after 15 minutes is marked as failed; just run it again.

The crawl connects to the server with the link’s SSL mode, just like the preview. It uses a regular desktop Chrome browser identity and scrolls each page so lazy-loaded images and scripts are checked too.

Run settings

Click Run settings next to the button to change how the crawl works before you start it. Run with these settings starts a report with them; Save defaults (or ticking Save as the default for this link) makes them the starting point of every new run of the link, including runs started through the API.

Pages left out by these settings are listed under Not tested with the reason (excluded, disallowed by robots.txt or beyond the page limit), and every report shows the Settings used.

Staging login

The credentials are sent only to your link’s domain and its www twin on the new server: never to other sites a page loads from, never through a redirect to another site, and never to the live site. They are stored encrypted, are never shown again after saving (only “saved” and, for long values, the last four characters) and don’t appear in the activity log. Replace enters a new value; Clear removes them. The Host, Cookie and connection headers can’t be set; use the cookie option for cookies. Share links show only which kind of login was used.

What it checks

The same problem on many pages is reported once, with the list of affected pages.

Old vs new server

Besides the browser crawl, DNSPeek fetches up to 10 URLs twice with the same simple client: once from the live site (normal public DNS) and once from the new server. The URLs are the home page, its http:// and www variants, a made-up URL that must not exist, and a few crawled pages. The report shows both sides next to each other: status, redirects, title, time to first byte, size, compression, HSTS and security headers, cookie flags (Secure, HttpOnly, SameSite), robots rules and the canonical URL.

Findings only come from differences that matter for a launch:

• a page that works live but fails on the new server (critical)
• search engines told not to index the new server, or a canonical URL pointing to another host (critical on the home page)
• HTTP no longer redirecting to HTTPS, or a different www / non-www redirect
• a missing title, lost compression, HSTS, security headers or HTTP/2, and cookies that lost their Secure flag
• a new server that answers more than twice as slowly as the live site (and at least 500 ms slower)
• unknown URLs that return 200 instead of 404, or a custom 404 page that isn’t used any more

If the live site is behind a CDN or firewall such as Cloudflare, differences the CDN may add itself (compression, HTTP/2, caching, HSTS, security headers, HTTPS redirects) are shown as info: they come back once the CDN points to the new server.

The comparison is skipped, with the reason shown, when the domain doesn’t resolve yet, already points to the new server, the live site can’t be reached, or it is turned off in the run settings.

To keep the load light, the new server gets at most 30 simple GET requests for these checks (robots.txt, sitemap, the 404 check, four redirect checks and the compared URLs), two at a time with a short pause, identified as DNSPeekQA/1.0. They stop early if the server answers “too many requests”.

DNS and email readiness

The report reads your domain’s public DNS as it is before the switch: nameservers, the A/AAAA/CNAME records of the domain and www with their TTL, MX, SPF (including how many DNS lookups it needs: more than 10 makes SPF fail), the DMARC policy, and DKIM keys on common selectors (Google, Microsoft 365, Mailchimp, Zoho, Resend and generic ones). A selector that isn’t found is never an error: custom selectors can’t be discovered from outside.

It then lists what to do, for example lowering the TTL to 300 seconds 24–48 hours before the switch, and the exact records to recreate first if you move to another DNS provider, so email keeps working. See the migration playbook.

After the DNS switch

Pro+Available on the Pro, Agency and Provider plans With DNS alerts turned on, DNSPeek re-runs the QA report automatically once the domain resolves to the new server. It crawls the live domain with the same pages as your last report before the switch and compares them: pages that broke, redirect to another place or lost their title, and new critical issues. You get a Post-switch check ready notification with the summary and a link to the report.

The re-run counts as one QA report of the month. If your plan has none left, you get a notification with an upgrade link instead. It runs once per switch, and only when there is a finished report from before the switch to compare with.

Platform-aware checks

The report recognises what the site is built with from the pages it crawled (headers, cookies, the page source and the files it loads) and shows it under the domain, for example Built with WordPress 6.4 · WooCommerce · PHP · nginx. Hover a name to see why it was recognised. A platform recognised from weaker clues reads “probably”; clues too weak to be sure are not shown at all.

It recognises:

• CMS and shops: WordPress (and WooCommerce, Elementor, WP Rocket, W3 Total Cache, LiteSpeed Cache), Joomla, Drupal, Magento / Adobe Commerce, PrestaShop, OpenCart, Shopware, 1C-Bitrix, TYPO3, Craft CMS, Ghost, Strapi and Adobe Experience Manager
• Frameworks: Laravel, Symfony, Django, Ruby on Rails, ASP.NET, Express, Flask, CodeIgniter and Yii, plus PHP, Python, Ruby and Node.js
• JavaScript apps and static sites: Next.js, Nuxt, Gatsby, Astro, SvelteKit, Remix, Angular, React and Vue single-page apps, Hugo, Jekyll, Eleventy, Docusaurus and Gridsome
• Web servers: nginx, OpenResty, Apache, LiteSpeed, IIS, Caddy and Kestrel
• Hosted site builders: Shopify, Squarespace, Webflow, Wix, Tilda, HubSpot CMS, WordPress.com, Ghost(Pro), Framer and others

Knowing the platform makes the advice specific: a missing uploads folder on WordPress points at wp-content/uploads, on Laravel at php artisan storage:link. Platform checks include WordPress database and critical errors, a stuck maintenance mode, Laravel, Symfony, Django, Rails and ASP.NET debug or error pages, Django, Drupal and Rails rejecting the domain name, Magento static files that were not deployed, and a Laravel front end that was not built. Findings show the evidence they are based on and a link to the platform’s documentation.

Hosted site builders

Shopify, Squarespace, Webflow and similar builders serve a domain only after it is connected in their dashboard, so a preview by IP can’t show the new site there. When the server IP you enter is one of a builder’s published addresses, DNSPeek warns you right after creating the link (the link is still created) and the QA report says so, with the builder’s own preview address to use instead.

What is not tested

Some things can’t be checked by an automated crawl. The report lists them under Not tested instead of reporting them as problems, and they don’t affect the score:

• Service workers are disabled during the crawl, so offline and PWA behaviour isn’t tested.
• Private network addresses are never contacted: DNSPeek blocks requests to internal or loopback addresses for security.
• Pages behind bot protection (a captcha or “Just a moment…” check) can’t be read. Allowlist the preview or check those pages manually.
• Platform-specific items: for a recognised platform the report adds what usually breaks after a move but a crawl can’t see, such as scheduled jobs (with the command to recreate them, e.g. wp cron event run --due-now), email sending, logged-in and admin areas, uploads, and for shops checkout, payments and webhooks.
• Pages left out by the run settings: pages that matched an exclude pattern (or no include pattern), pages robots.txt disallows, pages still queued when the page limit was reached, and checks you turned off (the live comparison or the active probes).
• Checks that need more data: checks that compare with the live site or probe the server directly (robots.txt, the HTTP/HTTPS and www redirects, the certificate’s names and chain) are listed here when that data wasn’t collected for the report.

How the score works

Every report starts at 100. Each finding deducts points by severity:

• Critical: 15 points
• Warning: 5 points
• Info: half a point, and all info findings together deduct at most 5 points

A problem found on many pages counts once, plus 1 point for every 10 extra pages (at most 5 extra points). A single category can deduct at most 35 points, so one systemic problem, like 40 broken images, does not hide everything else. The score never drops below 0.

The verdict follows the severities:

• Fix before launch: at least one critical issue, or so many warnings that the score is below 50
• Launch with care: no critical issues, but warnings to review
• Ready to launch: no critical issues and no warnings

Every finding comes with a recommendation for how to fix it.

Pages and reports per plan

Share the report

Open a finished report and click Copy share link. Anyone with that link can view the report without signing in, which is handy for a client or a developer on the hosting side. Save as PDF opens your browser’s print dialog with a print-ready layout.

Agency+Available on the Agency and Provider plans Reports on Agency and Provider plans are branded: they show “Prepared by” with your company name, logo, colour and support contacts. Set them up in Branding.

Reset the share link

To stop an old share link from working, click Reset share link and confirm. The report gets a new link straight away (copy it again with Copy share link), and anyone opening the old one sees “not found” instead of the report and its client comments. The report itself does not change. Whoever ran the report, the link’s creator, and workspace owners and admins can reset it; viewers can’t. Each reset is recorded in the activity log.

Making a link private resets the share links of all its reports at once, and switching it back to shared does not bring the old links back. If a client tells you the report link stopped working, the share link was reset or the link was made private. Either way, open the report, click Copy share link and send them the new one.