Creating and reviewing a project
Enter a required project name, choose an existing workspace Website and enter staging. Add Website opens the normal Website inventory and uses your package allowance, including sites under construction. Existing Website comparison chooses saved live reference or Staging-only. The same choice appears in Project setup and can change before another QA run. No published live site is needed for Staging-only QA. Before the first run, open the Website reference, launch decision, optional Runtime and protected access panels directly. After a run, the same controls remain in Project actions (…).
Saved checks, launch priorities and coverage
Saved check breakdown counts original check records as Passed, Warning, Failed, Partial or Not checked, including unavailable checks. This denominator is separate from page counts and does not change with filters. Launch review priorities show up to ten saved failures and warnings with affected URLs, failures first. Unavailable live comparisons appear beside the relevant staging page rather than repeating in launch priorities; their original saved check counts and details remain available. Read page details and QA Runs for remaining findings. Capped inventories and unavailable comparisons explain partial coverage; they are not proof every page is broken. Staging noindex may be intentional before launch, but live indexing and canonical destinations must be reviewed before publishing. Missing FAQ or general structured data needs relevance review, not a universal failure. The Redirected page card excludes slash-only normalization, while saved redirect counts and final URLs remain visible in details. A slash change alone does not prove a server redirect. Static forms and supported optional Runtime evidence do not prove submissions or unsupported browser journeys.
Results and filters
After a QA run exists, the project shows its actual Queued, Running, Failed or Completed state, saved metrics, Filters, page results and QA Runs history. A completed run is not launch approval. The compact page table keeps key staging and comparison evidence together; More columns reveals the remaining saved facts. Results default to all available saved evidence. Status, page, date and coverage filters narrow your review without collecting new data. Project actions keeps setup, optional reference, decision, Runtime, protected access, archive and deletion available. Before the first run, setup appears directly.
Client HTML report
Choose Project actions (…) → Client HTML Report, then create or open the saved report. It contains the saved launch summary and client-safe findings, without staging addresses or internal notes. Viewers need authorized access to the same workspace. It is a saved snapshot, not a live scan or a public link. Creating it does not add Launch QA findings to general Website reports or follow-up tasks; earlier saved report choices stay unchanged.
Runtime setup and installation status
Runtime QA is optional and installs on staging only. Open Enhanced Runtime QA, enable and save its configuration, then copy the matching snippet into staging. If the staging host changes, save the configuration again before copying. Installation status describes the last saved observation; it is not a current installation guarantee. Run QA explicitly to collect supported new evidence. Normal server QA continues without the snippet.
What Launch QA is
Launch QA keeps a saved launch review for your staging site. Launch QA works without installation. Enhanced Runtime QA adds rendered-page evidence for staging. Review findings alongside your own checks before making a launch decision.
Who should use it
An authorized workspace website manager activates Launch QA in Pulse Hub and opens Manage. Use it before a redesign, domain move or new website launch. Project controls and detailed staging evidence are restricted to authorized managers; clients receive only explicitly prepared safe summaries.
Existing Website or redesign
Choose the normal workspace Website for your redesign. Run QA prepares its saved reference automatically; there is no separate Capture baseline step. The Website continues to own monitoring and normal Website data; the project owns its launch review.
Staging-only or new website
Add a normal Website for the site under construction, then choose it for your named project and select Staging-only. Its Website URL may be staging while there is no live site. It counts toward your Website allowance. Staging-only QA needs no live baseline. When the live site is ready, choose a saved Website reference and change comparison mode for future runs. Historical projects, reports and results remain available.
Optional Website baseline
You can link a staging-only project to an existing Website in your workspace later. Open the project and choose Project actions (…) → Link / change Website baseline. Future runs use that Website’s saved evidence; linking does not scan or refresh it. Change Website or Detach baseline keeps both objects and all saved QA history. Linked projects appear in Website Detail under Launch QA. Missing saved facts remain Not checked.
Complete Website
New projects default to complete-site Launch QA. Historical selected profiles remain available in their saved projects. This review discovers a bounded set of eligible public staging pages and also considers saved mappings and linked Website page history. It is not an unlimited crawl. Each admitted page receives saved checks or explicit reasons for unavailable checks. Discovery and resource limits can leave coverage Partial.
Selected URLs
Historical selected-URL projects review chosen important pages and their saved live-to-staging mappings. Review each mapping before running QA. Results describe only the selected pages; they do not establish whole-site coverage.
Project setup
Activate Launch QA in Hub, create a named project, select a workspace Website and comparison mode, and save staging. New projects use Complete Website; older Selected URLs projects keep their original scope. Supported protected staging uses an authorized saved credential reference; never put credentials in URLs or Help requests.
Live/reference and staging URLs
The live/reference URL identifies the original or intended live site. Staging identifies the site under review. Keep the two environments distinct and verify the exact spelling. A missing live response shows Comparison unavailable beside staging evidence; open its information tooltip for the saved reason. It does not fail staging by itself or prove a comparison. Available means a saved staging response exists; Passed requires saved passing checks.
Automatic saved baseline
Run QA prepares or reuses the saved Website reference during your explicit action. Opening a project never collects new evidence. Saved values can be older than the QA run; missing facts remain unavailable, not successful comparisons. Refresh the reference Website when ready and run QA again, or choose Staging-only. A changed live domain uses new reference evidence for future runs and keeps earlier snapshots unchanged. Conflicting mappings need review first.
Mappings
Optional page mapping in Project actions follows the current comparison setup, even while you view an earlier run. Save the old live URL and its matching staging URL when paths differ. Mapping status describes the page relationship and is separate from QA status. Live mappings must share the saved reference hostname. If a saved reference conflicts, explicitly confirm the correct future reference; existing runs stay unchanged. Complete Website also uses automatic same-path matching; a changed redirect destination, missing target or new staging page may need review.
Running QA
Choose Run QA explicitly. Queued and Running mean work is in progress and can take a few minutes. Leave the page and return to view saved progress if needed. Normal server QA requires no installation. Completed describes run processing, not approval to launch; inspect failures, warnings and incomplete coverage. Failed, Warning, Passed, Not checked and Partial counts describe saved checks; linked issues are separate records, labelled Linked issue records.
Summary cards and quick filters
Cards count pages in the selected saved run. Choose a card or quick filter to review Passed, Needs review, Restricted, Redirected, Mapping review, SEO, Technical or Content findings. Categories can overlap, so adding all finding cards does not equal total pages. Cards are the quick filters; distinct Differences and contact-change filters use saved data. Runtime filters appear only when that run has saved runtime evidence.
Saved result filters and pagination
Search page paths, URLs or saved titles. Combine page type, HTTP, indexability, mapping and QA status with checked dates. Filters open by default. Coverage defaults to All and offers Checked or Unchecked for a narrower review. Filters combine before pagination; sort by path, QA status or checked time. Clear filters returns to the selected run. Pages show up to 20 rows at a time.
Detailed comparison table
The table uses available content width and scrolls horizontally within its own area. It presents page identity, live/staging URLs and HTTP where applicable, metadata, structured data, links, images, phone comparison, public Email, mapping, QA status and saved check time. Long values are shortened in rows; use Open comparison for details.
Per-page comparison and evidence sources
Open comparison shows supported saved families and their individual check results. Server scan means fetched source from the run. Frozen Website baseline means historical Website evidence, not a current live fetch. Operator-authorized Runtime probe means an explicit staging capture. Not recorded means an older run did not save that fact. Presentation prefers the saved bounded link inventory and authoritative executable-script tracking evidence. Older unverified tracking signatures are labelled as legacy; original evidence stays saved.
Unchecked evidence and fact groups
Page details group HTTP, SEO, content, contact, tracking, schema, social, platform and links/media facts. Coverage defaults to All, including unavailable facts. Choose Checked to hide non-actionable unavailable facts, or Unchecked to review them; totals always include all saved evidence. Not detected means the detector ran and found no signal; supported absence remains visible. Not recorded means the saved fact is absent; Not checked means the check could not be performed. Staging detection and live comparison are separate. Recorded absence can compare as Match or Changed; a missing live reference stays Not checked or Not applicable. Coverage also controls saved Site checks and other run checks. Saved outcomes appear with their fact as evidence rather than duplicate rows. Supported missing schema and FAQ evidence remains a relevance review even when both sides match; missing social fields alone do not create a new SEO requirement. Historical records stay saved, while current classifications and linked findings can correct an old false failure. Link inventories use the first 40 occurrences, with unique internal/external HTTP targets and separate fragment, mailto, telephone and unsupported counts; capped inventories are Partial. Static HTML forms are separate from rendered DOM evidence and neither proves submission. Saved CTA candidates omit blank, skip and close controls while keeping real action labels. Historical candidates remain saved unchanged.
Protected staging access
Only use Protected staging access if staging requires HTTP Basic Auth. Choose an authorized Saved Basic Auth credential; No credential — public staging is the default. Never paste passwords into URLs or Help requests.
Public email and mailto evidence
The main saved-page table shows the first public email and +N for additional saved public addresses; the tooltip shows a bounded inventory. New runs save bounded public server-page email addresses and mailto links, normalize letter case, and compare them when both saved sides exist. Email changes can show Match, Missing on staging, Added on staging or Changed. Missing or capped evidence is Not checked or Partial. Form values, private or hidden markup, script data and Runtime private data are excluded. Older saved runs remain unchanged.
Site checks
Complete Website keeps robots.txt availability, sitemap XML availability, HTTPS availability and HTTP-to-HTTPS behavior in a separate Site checks section. These are saved run checks, not a site health score. Robots availability does not prove crawl permission. New Complete Website runs also save wildcard robots summaries, bounded sitemap document counts and Live/Staging llms.txt reachability under AI Readiness / Crawler Readiness. This does not prove specific AI crawler permission, AI mentions or citations. Independent DNS health, certificate expiry and alternate WWW-host redirects show exact Not checked reasons. Missing llms.txt is Not detected even when both sides match; an unavailable file is Not checked. A possible CMS clue cannot establish a platform change. Passive CMS, hosting clues with confidence and inline fonts appear in page detail; external stylesheets are not fetched for font discovery.
HTTP, final URLs and redirects
Read HTTP with its saved time. A saved 200 does not guarantee current availability or correct content. Final URL and redirect count describe the saved response; paths are compared across live and staging hosts. Restricted identifies 401/403 responses. A new-on-staging page is not failed solely because its live counterpart is absent; real staging and content findings still apply. Passed Page checks show Checked with the saved HTTP outcome. Soft-404 source can produce a finding despite HTTP 200.
Robots and indexability
Indexability uses supported page robots metadata and saved response directives. Missing directives remain Not checked rather than an invented pass. A staging noindex can be intentional; confirm the intended live configuration independently before launch. Robots.txt availability is separate from page indexability.
Canonical, title, description and H1
Compare supported saved title, meta description, primary H1 and canonical facts. Canonical/final URL path comparisons account for different environment hosts. Missing values do not establish a match. Review unexpected content and redirect changes before launch. First H1, H1 count and a bounded heading inventory are separate. Older joined heading text is labelled saved legacy text and is not treated as the first heading.
Schema, FAQ and social metadata
Saved source can expose schema types and formats, FAQ schema presence, and Open Graph/Twitter image presence. New saved source also compares Open Graph title, description and image URL, plus Twitter card, title, description and image URL. Parameterized or unsupported image URLs are omitted and marked Partial. Saved facts do not establish valid rich results or successful sharing. Bounded or invalid source evidence can be Partial; older runs do not gain these facts automatically.
Links, images and forms
Source inventories count supported links, images, missing/empty image alt and forms. They do not click links, load every resource or submit forms. At most two supplemental safe same-site resource checks are shared across a run; other items remain inventory-only or Not checked. A form count does not prove a working submission.
Phones, click-to-call and call tracking
Details show server live/staging phone lists where recorded, bounded tel-link lists/counts, provider signatures and Google/WhatConverts source signatures. Compare matched, added, removed or changed values. Not detected means an observed inventory was empty; Not checked means evidence was unavailable. Visible phone text includes bounded public international + formats and North American numbers. Equivalent formats are deduplicated. Click-to-call links are separate evidence, including tel-only links without visible phone text. Explicit tel links support format-only international normalization with a leading + and 8–15 digits; this does not validate assignment or working calls. Local values retain bounded display evidence without guessing a country. Dates, order IDs and ordinary numeric text are not promoted to international phone evidence.
Tracking evidence limits
GA/GTM, WhatConverts and call-tracking signatures identify source evidence, not successful analytics delivery, call operation or dynamic number replacement. Runtime v1 records known script-host presence only. Runtime phone/tel lists and number substitution are Not checked in v1; perform your own authorized call and analytics acceptance.
Optional Enhanced Runtime QA
Enable optional staging runtime capture in the project. A fresh QA run freezes that configuration. The optional probe shows its enabled/disabled configuration and last saved observation; configuration alone does not prove current installation. The probe saves six facts: form count, title presence, canonical presence, Google tag script-host presence, WhatConverts script-host presence and CallRail script-host presence. It does not capture page text, phone numbers or canonical URL values.
Installing the Runtime Probe
Open Installation and use Copy code for the public snippet in Enhanced Runtime QA. Install it only on staging using your normal site editing process. Keep it limited to the approved staging target; no live production probe is required. Run fresh QA after enabling it. The script makes no capture on page load. Open the exact saved staging page over HTTPS without a query or fragment.
Capturing runtime evidence
In the saved page comparison, request a single-use capture code. On that exact staging page, open the browser console, call PulseLaunchQA.capture(), and enter the code into its prompt. The code expires after three minutes and works once; do not share it. Return to Pulse and reload results. Each page accepts one immutable capture; use a fresh run for another observation.
Removing or revoking Runtime Probe
Remove the script from staging and disable runtime capture in the project. Saving configuration revokes unused codes and requires a fresh QA run before new captures. Previously saved runtime facts remain historical. Runtime not configured describes frozen configuration, not proof that a script is absent.
Runtime privacy and comparison
The probe never collects form values, passwords, cookies, sessions, page access tokens, CSRF values, query secrets, raw HTML/DOM, arbitrary page text, private submissions, Vault data, browser storage or user-entered data. Runtime is an operator-authorized observation, not independent proof of an uncompromised website. Both agree compares supported saved facts; Runtime difference needs review. Runtime not observed means no capture was saved; Partial means a bounded capture/source cannot establish complete agreement.
Understanding result states
Passed means the specific check completed with its stated factual outcome, not that the whole launch is safe. Needs Review gathers failures, warnings and partial page evidence. Not checked means a check could not run or lacked supported facts. Not recorded means history lacks the fact. Not applicable means the check does not apply to the scope. Partial means incomplete coverage; Restricted means access was denied. Read each reason.
Saved data, freshness and rerunning
Opening results, Help or Settings reads saved information and does not recheck websites. Historical facts can differ from current content, HTTP or redirects. Select the intended saved run and review its time and source. After changing staging, explicitly run QA again; after changing runtime configuration, create a fresh run and capture again. Existing observations remain unchanged.
Archive and Restore
Archive keeps the project and its review history while removing it from Active projects. Use Archived projects to open it. Authorized users can Restore project to return it to Active. Choose Archive when you want to retain evidence.
Permanent Delete: removes and preserves
Delete project remains available for authorized users after baseline, QA runs and completed evidence, including archived projects. Open Delete project, read the warning, check confirmation and submit. Wait for running QA to finish. Deletion permanently removes project-owned launch history, mappings, schedules and runtime observations. It preserves the linked Website, page audits, scan history, monitoring, scheduled site refresh, unrelated projects and other workspace data.
Post-launch watch
For linked Website projects, the existing bounded post-launch watch requires an explicit launch start and enablement. Choose the supported duration and frequency, then review saved verification and issue status. Staging-only targets have no post-launch watch. This does not replace monitoring or silently approve a launch.
Browser Journey
Browser Journey remains ON HOLD and unavailable. It is separate from server Launch QA and the optional count/presence Runtime Probe. No journeys, form submissions, payment tests or browser automation are enabled by this feature.
Troubleshooting
If Run QA is unavailable, check add-on activation, operator permission, staging setup and the linked Website baseline. For Partial, inspect page limits and individual reasons. For Restricted, check approved staging access. For missing live facts, verify reference spelling and public availability. For missing runtime facts, check enabled frozen configuration, script placement, exact HTTPS page, fresh unused code and removal of query/fragment. Do not paste credentials or capture codes into support requests.
Typical launch workflow
Create the project, choose scope, save staging/reference and mappings, capture the linked baseline, run QA, review cards and every incomplete finding, make changes and rerun. Optionally capture supported runtime facts. Perform separate manual form/call/analytics checks. Record your launch decision. For linked projects, explicitly start and configure the post-launch watch when appropriate.
Recommended pre-launch checklist
Confirm the intended page coverage and live-to-staging mapping. Review HTTP, redirects, robots intent, canonical, title, description, H1, schema, links, images and forms. Review phone/tel and tracking signatures, missing references and all Partial/Not checked reasons. Separately test public forms, calls, analytics and the actual live indexing configuration. Treat runtime count/presence as supplemental.
Recommended post-launch checklist
Check the actual live site and key redirects, remove staging-only restrictions where intended, verify indexing and canonical destinations, and perform your own authorized forms/calls/analytics acceptance. For linked projects, review enabled post-launch watch results and normal monitoring. Keep useful launch history with Archive; use permanent Delete only when you intend to remove that project evidence.
