PulseWMS Help Center

1. What PulseWMS Is

PulseWMS is a website health and monitoring dashboard for agencies managing client websites. It centralizes browser-side events, external uptime checks, page audits, DNS diagnostics, technical health signals, and critical alerts without requiring a WordPress plugin, private admin access, or server log access.

1A. Appearance Toggle (Light / Dark)

PulseWMS includes per-user Appearance preferences with System, Light, and Dark options. Logged-in user preferences are saved in the database through each user profile; browser storage is not the source of truth.

To prevent light-mode flash after refresh, navigation, or action submits, Pulse applies the user theme class during server render and keeps a tiny early script only for System theme browser-preference fallback.

Dark mode uses a soft slate/navy palette for readability and keeps orange accents for primary actions. It is intentionally not pure black.

1B. Pulse Hub

Pulse Hub is the client workspace catalog for Extensions, Add-ons, Integrations, Templates, Themes, and Workflows. Open it from the workspace sidebar under Hub. The dedicated Hub docs page explains the catalog in more detail.

Open Pulse Hub Docs

Safe browsing: Hub pages use saved central catalog details only. Opening Hub, Hub docs, or Hub detail modals does not run scans, AI, PageSpeed, Google/provider calls, payment actions, emails, or external requests.

Package access: Pulse Hub is controlled as one package feature group. Browser Extension stays visible as a free Extension item. Visual Change Watch, AI Visibility, and Trust Checker can be activated for the whole workspace when the workspace package includes Pulse Hub. Other planned add-ons/widgets stay Coming Soon until their real workflow exists; Coming Soon cards do not show Details, docs, upgrade, or activation buttons.

Activation behavior: inactive or deactivated add-ons do not show their extra settings, report/proposal options, buttons, filters, or add-on-only evidence areas. Activation only enables access/config; checks still run through explicit actions or background monitoring, not by opening Hub.

Visual Change Watch: a workspace-level add-on for saved public page change review. When activated, authorized users can configure a website page, create an explicit baseline, run later saved public-page comparisons, review before/after diff history, and approve or ignore changes. Current checks use saved public text snapshots; true browser screenshot/image comparison requires a future browser-capture backend.

AI Visibility: a workspace-level add-on with website-specific brand/service/prompt configuration. AI runs only from an explicit authorized action using the configured provider, then saves a client-safe visibility classification and recommendations. Hub does not run AI on page load.

Trust Checker: a workspace-level add-on with website-specific saved-evidence checklist results for policy/contact/proof/form/trust readiness. It is guidance only and does not guarantee payment-provider approval. Hub does not run live trust/provider checks on page load.

Brand Studio: a planned Hub item for client-safe branding surfaces. Internal white-label controls stay outside normal client Hub details.

Browser Extension: appears under Extensions as a free Hub item. Download/setup still follows the normal workspace extension access rules. Hub does not show passwords, tokens, cookies, or session values.

WordPress Plugin: planned / Coming Soon. Pulse remains platform-agnostic and does not require a plugin for core monitoring.

Templates: planned / Coming Soon for reports, proposals, onboarding, and workflow templates.

Workflows: planned / Coming Soon for guided setup, review, cleanup, and reporting flows.

1B. Proposal Center

Proposal Center is a client-facing sales/proposal workspace. It translates saved technical findings into business problems, impact, recommended services, and evidence links.

Saved-Data Only: Proposal Center does not trigger scans, uptime checks, DNS lookups, or PageSpeed API calls during page load.

Separate From Client Report: Proposal Center is not the same as View Client Report. View Client Report remains the neutral saved report/export area.

Two Proposal Flows: Tracked Websites flow uses tracker-detected websites only and follows select website -> Prepare Latest Proposal Data -> proposal form/workspace. Manual Proposal flow opens directly for untracked/new prospects.

Proposal Refresh: Prepare Latest Proposal Data queues the same normal full-site refresh used by Refresh Site Data, uses background processing, and does not run scanner logic during page render.

Proposal Scan Progress & Cancel: Proposal scan progress is shown from saved ScanJob data and can be canceled safely. Completed proposal scans automatically continue to the proposal form.

Proposal Form: all client/project/scope/timeline/template/pricing fields are optional and can be filled gradually while drafting.

Who Can View or Create: users with proposal access can open saved proposals for their workspace. Create buttons stay hidden until the user also has permission to create proposals and the current workspace plan allows new proposal creation.

Hidden Create or Export Buttons: if a create or export action is missing, your workspace role, granted access, or current plan may allow view-only access. Ask a workspace Admin if you are unsure.

Problem-First Output: Proposal evidence preview focuses on saved risks/issues by default and does not fabricate findings.

Generated Proposal Preview: Proposal Center currently uses a deterministic template-based generator from saved website evidence and optional form values. Empty optional fields are skipped or shown with clean fallback language.

Proposal Type: Proposal Builder includes type-specific planning such as revamp, new build, improvement/fixes, technical audit, SEO, speed, tracking, maintenance, migration, content improvement, and custom proposal mode.

Smart Manual Proposal Questions: Manual Proposal first narrows fields by service category, then by Website project type, SEO type, or advertising channel. Inactive questions are excluded from saved scope and exports, so a small-fixes proposal does not inherit redesign questions and a Local SEO proposal does not inherit technical-audit questions.

Deterministic Content Library: Proposal text is assembled from a reusable paragraph library that adapts to selected services, current/target platform context, industry type, and saved technical findings.

Opportunity Analysis: Proposal generation now uses saved-data opportunity analysis to summarize page inventory, page-type counts, top opportunities, and phased recommendations.

Optional Add-ons: Proposals can include optional add-ons for SEO, AI Search Readiness / GEO, website scope, landing page / CRO, conversion tracking, Local SEO, Meta Ads, content, and care plans. Add-ons unlock separate proposal sections without mixing them into the core scope.

Broad Scope Warning: if many add-ons are selected, Proposal Center shows a soft warning so users can keep the client scope focused before preview, save, or export.

Saved-Data Behavior: tracked website proposals can use saved scan/report evidence where available, including website quality, SEO visibility, landing-page/tracking readiness, Local SEO readiness, Meta Ads readiness, and AI Search Readiness / GEO when eligible. Missing saved evidence uses safe neutral wording and never invents facts. Opening docs or proposals does not run live scans, PageSpeed, AI/provider, email, payment, or external calls.

Saved Evidence Summary: proposal previews and exports now group saved evidence into plain-English sections such as Website / content, Schema / search visibility, Forms / conversion, Tracking / measurement, Ecommerce, Local proof, and Performance / technical risk instead of repeating the same detector phrases.

AI Search Readiness / GEO Opportunity: tracked website proposals can include an editable saved-data GEO opportunity section based on saved readiness signals, recommendations, and evidence gaps. The section is client-safe, does not call optional assistant services, does not run live scans or PageSpeed, and does not promise AI rankings or citations.

Page Count Overrides: Proposal forms support saved-scan estimates with manual overrides for current/final page counts, blog inclusion, blog count, pages to migrate, and pages to consolidate.

Client-friendly Tone: default proposal wording is simplified for non-technical clients; a more technical tone can be selected when needed.

Platform and Industry Context: Proposal output can include platform-aware guidance (for example Weebly/Wix/Squarespace migration context or WordPress optimization guidance) and industry-specific strategy paragraphs (for example local service trust flow or church/nonprofit accessibility and content simplification).

Timeline and Hours Guidance: If timeline/hours are not manually entered, Proposal Center uses deterministic page-count ranges to suggest editable timeline and effort baselines.

Saved Evidence Mapping: Current Site Assessment paragraphs are generated from saved issue evidence only (for example broken pages, search visibility, performance, form errors, DNS/SSL risk, and uptime warnings) and limited to top-priority findings.

Risk Fix Opportunities: Proposal Center can now turn saved Malware & Injected Code Evidence into client-safe fix opportunities such as mixed-content cleanup, suspicious script review, hidden or insecure embed review, suspicious outbound-link cleanup, and possible defacement review. Normal inventory-only scripts, common embeds, and common dependency inventory are not turned into proposal problems by default.

Template/Reference Links: Structured template/reference links are rendered in proposal output with title, URL, and note, or a clean placeholder if links are not provided.

Editable Section Controls: each proposal section can be reordered, marked Draft/Ready/Needs Review/Optional, and included/excluded from exports while still staying saved in the workspace.

AI Proposal Enhancement (Optional): AI improve actions are explicit-click only. On generated review/workspace pages, Save & Improve with AI saves the draft first and then enhances editable sections. On saved proposal workspace/library pages, Improve with AI enhances directly.

No Auto AI Runs: AI does not run on page load, does not run during normal proposal rendering, and does not run during PDF/DOCX exports.

Section-Level AI: Saved proposal workspace sections can be enhanced one section at a time with explicit user action. This updates only the selected section and preserves section include/status/order controls.

Optional AI Help: Optional AI improvements are explicit-click only. If AI help is unavailable, saved deterministic proposal drafts remain editable and exportable.

Availability: if optional AI help is unavailable, the saved deterministic proposal draft remains editable and exportable.

Fallback Safety: deterministic proposal generation remains the baseline. If AI enhancement fails, the original saved draft remains unchanged.

Quota/Rate Limits: Optional assistant services can return temporary usage limits. If you see a usage-limit message, wait a few minutes and retry. Continue editing/exporting with deterministic saved sections in the meantime.

Privacy: private credentials and service configuration are never shown in proposal screens or exports.

Save/Reopen/Edit: Save keeps users on the same proposal workspace and confirms success; Proposal Library remains available for reopen/edit later.

Proposal Workflow: saved proposals use simple client-facing states: Draft, Ready to Review, and Sent / Exported. These labels help teams separate in-progress work from items ready for review or already shared.

Proposal Exports: Proposal Center has separate PDF and DOCX exports for proposal output. These are separate from View Client Report / Save Report PDF and do not run scans or external checks during generation.

Saved Export Source: proposal PDF and DOCX files use the saved proposal sections already stored in the workspace. Exporting does not run a new scan or optional AI/provider action.

Report Readability: client reports and exports show grouped saved evidence summaries and human-readable missing states such as Not detected in saved scan, No saved data yet, Refresh Site Data required, or Google not connected.

Saved Data Promise: Reports and proposals use saved website data unless you choose an explicit refresh or sync action. Opening a report, proposal, public help page, or documentation page does not run a live scan, Google sync, PageSpeed check, optional AI request, email, payment, or external provider action.

Recent Saved Proposal Evidence: Proposal Center can now turn saved AI Agent Readiness gaps, Heading / URL Intelligence findings, and saved Google Search performance opportunities into concise business-ready proposal talking points when that evidence exists for the selected website. It stays deterministic and uses saved Pulse data only.

Google Data Benefit: Connect Google to unlock real SEO, traffic, conversion, and local visibility insights. PulseWMS uses saved Google evidence to make reports and proposals more accurate after data is connected, mapped to the right website, and synced by an explicit action.

Website Google Mapping: each tracked website can show whether saved Google data is not connected, mapped but not synced, or synced. Until a website is mapped and synced, reports and proposals show a clear missing state instead of using unrelated workspace-level Google data.

Audit vs Tracking: Page Audits can show page-wise saved Google Search metrics and practical heading/URL columns when saved data is available. The Tracking tab keeps global saved detector, provider, and Google enrichment summaries instead of repeating page rows.

Google Page Metrics: page-wise Google Search columns appear only after the workspace Google account is connected, the website mapping is saved, and an explicit sync stores Search Console data. If any step is missing, Pulse shows a safe missing state instead of using unrelated website data.

Notification Center: the bell badge shows the exact unread notification count for your current shell or workspace scope. The bell dropdown is only a short latest-unread preview. In Notification Center, choose 20, 50, 100, 500, or 1000 rows per page; the page keeps read and unread history across the full authorized saved history; 1000 is a page size, not a total history limit. Alerts from a workspace you no longer access are hidden. Opening the page does not change anything on GET; a same-session POST can acknowledge only visible unread items on the selected page. Repeated copies of the same saved form or browser error are combined for a short period; different pages, forms, or messages remain separate.

Email Preferences: open your own workspace preferences from the relevant workspace entry in Profile / Appearance. The checkboxes are on your Workspace Member Access page and apply only to that workspace. They cover optional critical website alerts, form errors, uptime incidents, domain expiry alerts, and SSL certificate expiry alerts. Alert emails are intentionally short: issue summary, website/workspace/time, and a Pulse link to saved evidence. The checkboxes do not change in-app bell notifications, login/security emails, or billing/account-critical emails. JavaScript errors and Browser UX hints stay as saved Tracking evidence only; they do not create email or bell alerts by default. DNS records and DNS changes remain saved evidence in DNS & Infrastructure, but Pulse does not send DNS-change email or bell alerts by default.

Saved expiry alerts: domain expiry emails use the latest saved RDAP data and SSL expiry emails use the latest saved Pulse page-audit data. Pulse does not run a live domain or certificate lookup when you open dashboard pages. Current saved thresholds are domain 60/30/7/1 days and SSL 30/7/1 days. During the same saved expiry window, Pulse reuses one active bell alert per recipient instead of adding repeated duplicate rows. If no saved expiry data exists yet, Pulse cannot send those expiry emails until a later refresh stores it.

Export Spacing: PDF/DOCX exports normalize repeated blank lines and include only sections marked for export.

Browser UX Evidence: Proposal Center can include saved browser UX diagnostics (for example broken images, layout overflow, and slow interaction signals) when captured by the one-line tracker. If no saved data exists, Proposal Center shows not captured yet instead of inventing findings.

Tracker Reminder: continue placing the one-line tracker in the site footer or before the closing </body> tag.

1C. Proposal Permissions & Plan Access

Proposal access can be different for each workspace user. Some users can open the saved proposal library but cannot create new proposals, save new drafts, or export files.

If a Create, Save, PDF, or DOCX action is missing, PulseWMS is usually protecting your workspace plan limits or your workspace role permissions. This keeps view-only users from accidentally editing proposal data.

When in doubt, ask a workspace Admin to confirm whether your workspace plan allows proposal creation and whether your user account has proposal create/export access.

1D. Proposal Add-ons & Scope Options

Proposal add-ons let you expand a proposal in a clear way. Examples can include SEO, AI Search Readiness / GEO, landing pages, conversion tracking, Local SEO, paid ads, content help, or ongoing care plans.

Add-ons are explicit choices, not hidden guesses. That means a Website proposal does not automatically inherit SEO or ads language unless those add-ons are actually selected.

If no saved evidence exists for an add-on, PulseWMS uses neutral wording and simple placeholders instead of inventing technical findings.

1E. Proposal Preview, Save & Export

Preview, save, reopen, PDF export, and DOCX export all use the same saved proposal content. This keeps the proposal wording consistent across the workspace and the final client files.

Opening a preview or export does not run a new scan, Google sync, PageSpeed test, or optional AI request. Proposal output comes from saved website evidence and the scope choices already selected in the proposal.

If a section feels too broad, edit the scope, proposal type, or add-ons first. PulseWMS will keep the proposal focused instead of mixing unrelated services together.

1C. Saved Data & Account History

PulseWMS keeps saved monitoring, proposal, support, report, and workspace history so users can return to previous evidence and continue work safely.

Client View: workspace users can view their authorized saved records, reports, proposals, tickets, and Vault items according to their role.

Operator-Managed Safety: backup, restore, merge, retention, and recovery procedures are handled only by authorized Pulse operators through owner-only runbooks. Client docs do not include commands, file paths, or private recovery procedures.

1D. Pulse Operations Boundary

Client users should use dashboard readiness indicators and contact their Pulse administrator when a setup item needs attention.

Safe Page Loads: scans, uptime checks, PageSpeed checks, optional AI, email, and billing-provider work never start just because a client opens a page.

Private Configuration: provider credentials, security settings, server configuration, and recovery runbooks are never shown in client documentation.

Workspace, Packages, and Vault: workspace scoping, package entitlements, monthly usage counters, billing status, and Pulse Vault are part of the client workspace experience. Access stays role-based and workspace-scoped.

Install PulseWMS on desktop or mobile: signed-in users can install PulseWMS from Workspace Settings when their browser supports it. Chrome and Edge on desktop can install PulseWMS as an app, and Android browsers can add/install it to the home screen. The installed app always uses the PulseWMS product name and PulseWMS icon, not workspace, agency, or client branding. Workspace branding can still appear inside PulseWMS, reports, and eligible emails where supported. Existing installed apps may need a browser refresh, uninstall/reinstall, or browser metadata refresh to pick up corrected name/icon changes. PulseWMS does not store your private workspace pages, Vault data, billing pages, reports, notifications, or API responses for offline use; only safe app shell assets and a generic offline screen may be cached.

Tracker Domain Update: if your tracking snippet stops loading after a domain change, contact your Pulse administrator and refresh the snippet from Website Detail when instructed.

1E. Workspace Status

The client Workspace Settings page includes safe workspace status indicators for quick triage. Operator-only setup, private service configuration, backup, and recovery details stay outside client documentation. Client settings use saved database rows and safe workspace/package indicators only.

Workspace Launch Checklist: the main dashboard includes a first-run setup checklist for first website, first scan, uptime evidence, team member, Vault credential, report, and support ticket milestones. The checklist uses saved workspace data only and links to existing workspace pages; it does not start scans or external checks when the dashboard opens.

Operations Boundary: local commands and private server runbooks are kept out of client documentation.

2. Product Flow Overview

Saved Data: PulseWMS stores saved website, scan, uptime, form, alert, and support history for the current workspace.

3. One-Line Browser Tracker

5A. Tracker Installation

The one-line Pulse tracker is installed on the public website, usually in a shared header, theme setting, tag manager, or builder custom-code area. It does not require a WordPress plugin.

Install it only on the public pages you want monitored. PulseWMS reads safe browser-side signals such as page views, simple form-error events, JavaScript errors, and compact UX warnings without collecting passwords, hidden form values, or private admin data.

If the tracker is missing, Pulse can still show saved uptime and scanner data, but browser-driven signals may remain empty until the tracker is installed correctly.

5B. Tracker Verification & Test Events

After installation, open the public website in a real browser and confirm that Pulse receives a saved browser event. The approved browser test flow remains the safest way to confirm the tracker is live.

Verification can include a normal page visit, the manual tracker test flow, or a safe JavaScript error test when your team is ready. Results appear in saved browser-related areas after the event reaches Pulse.

If the tracker still looks inactive, check the page source placement, caching, consent/banner behavior, and whether the browser is loading the public site version you expect.

2A. Workspace Foundation

Each PulseWMS workspace keeps its websites, reports, proposals, tickets, Vault items, package limits, and users scoped to that workspace.

Package Basics: packages control workspace limits such as websites, refresh usage, exports, AI assistance, team capacity, Vault access, and related features.

Package Management: Pulse administrators manage package display fields and known feature limits. Client workspace users cannot edit global package definitions.

Package Availability: Pulse administrators can create packages and enable or disable their new-buyer visibility. Disabled packages are hidden from new package selection while existing subscribed workspaces keep their saved access. Unused custom/test packages can be deleted by owner-only POST action, while system packages or packages with subscriptions/history/provider mapping are protected and should be disabled instead.

Package Editor Safety: normal workspace admins cannot edit global package definitions. Package readiness is shown with safe yes/no status only; private payment configuration is never printed in client docs.

Backend Feature Gates: plan checks are enforced in backend action routes, not just hidden in the interface. Gates currently cover website registration, scan queueing, PageSpeed scan module use, new proposal creation, Proposal AI, Website Assistant AI, PDF report exports, and CSV exports. Existing saved data remains viewable/editable where safe.

Package Display: the authenticated Plans page shows active packages, the current workspace plan, key limits/features, billing status, and safe checkout availability. It is not a public marketing pricing page.

Package and Limit Messages: Billing / Plans explains what the current package includes, what may pause when a workspace is restricted or suspended, and how workspace admins can upgrade or contact support. Saved workspace data remains retained during billing restrictions.

Signup / Workspace Foundation: new accounts can create a workspace and choose an available package. Disabled packages are hidden from new buyers while existing subscribed workspaces keep access to their saved plan.

Multi-Workspace Switcher: a single user/email can belong to multiple active Pulse workspaces. One-workspace users enter the dashboard directly; multi-workspace users choose a workspace from the workspace chooser, and the sidebar shows Switch Workspace only when more than one active membership exists. Dashboard data is scoped to the selected workspace.

Already Signed In: if you open the Login page while already signed in, Pulse sends you to your safe workspace, workspace chooser, or agency dashboard destination instead of showing a new login form.

Create Another Workspace: if you already have a PulseWMS account, sign in first and then choose a package to create another client workspace under the same email. This does not create agency/system access.

Google Sign-in Foundation: Google sign-in appears only when your Pulse administrator has enabled and verified it. Private OAuth configuration is not shown in client documentation.

First Website Onboarding: empty workspaces show a guided first-website flow. The onboarding form adds a website to the current workspace and respects the workspace website limit. It does not automatically run Refresh Site Data, call AI, call PageSpeed, or install the tracking snippet.

Package Selection Before Signup: Create Workspace starts with package selection when public signup is available. No live checkout starts unless billing and public buying have been configured and explicitly enabled by Pulse operators; packages may show Coming Soon while remaining visible for review.

Free / Starter Claim: the Free or Starter workspace option can be claimed once per user account. If you already used the one-time free option, sign in and choose a paid package to create another workspace.

Workspace Members and Roles: client Admins can create or edit workspace users, choose Admin/Manager/Member/Viewer roles, and grant the separate Allow Credentials / Vault access checkbox. Admin includes the Vault area automatically; new Manager/Member/Viewer invites start with the Vault-area checkbox checked by default, and admins can still turn that area access off later where role policy allows. Managers can review member and package status without billing management. Standard members see workspace Admins and Managers only.

Blocked Members: if a member is blocked for a workspace, that member cannot access that workspace. Their global PulseWMS account and any other workspace memberships remain active.

Disable / Close Workspace: the card appears only for closeable client workspaces. Workspace Admins can close a client workspace from Workspace Settings with typed confirmation. This preserves saved data but pauses monitoring, tracker intake, shared report links, alert emails, and internal/manual billing state until reactivated. It does not contact payment providers or delete users, websites, reports, proposals, tickets, or Vault records. Agency, reseller agency/main, owner/system, and other protected workspaces are not closed from client settings.

Vault Area vs Secret Reveal: the workspace Vault checkbox controls sidebar/direct-page access to the Vault. It does not reveal encrypted passwords. Secret reveal/fill/edit remains owner/admin or explicit per-credential permission and stays explicit, permission-gated, and audit logged.

Profile Image: signed-in users can upload an optional JPG, PNG, or WebP avatar from Profile / Appearance. Pulse validates small media uploads, falls back to initials when no avatar exists, and keeps production media serving separate from static files.

Support Tickets: workspace members can create support tickets with category, priority, optional related website, thread replies, filters, pagination, and status history inside Pulse. Admins manage workspace tickets, managers can view/respond in their workspace, and members/viewers see their own tickets.

Ticket Safety: ticket threads are not a credential channel. Do not add passwords, vault contents, tokens, private keys, or other sensitive values. Private workspace notes are visible only to allowed workspace roles. Tickets always keep in-app notifications available.

Workspace Ticket Scope: tickets stay inside the current workspace. Replies and status changes happen only when an authorized user submits them. Opening a ticket does not send a reply or change its status.

Email Notification Foundation: ticket-created, visible-reply, and visible-status-change emails are sent only when the Pulse operations team has enabled email delivery. Ticket emails use safe metadata and links instead of private thread text.

Email Verification: optional password-login verification may require a short-lived emailed code when enabled by your Pulse administrator. Expired, used, or attempt-limited codes are denied.

Session Timeout: to protect workspace access, Pulse may sign you out after about 24 hours of inactivity. Save long edits regularly if you are stepping away.

Vault Password Manager: Vault stores approved login items for websites and client tools. Use Vault only for credentials your workspace is authorized to manage, and never paste passwords into tickets or docs.

Pulse Vault UI: Add Credential stays at the top, saved items render as cards with detail popups, and the category dropdown covers common CMS, hosting, domain, DNS, email, social, payment, analytics, and other login buckets. Card details never include a raw password during normal page load.

Client Knowledge Scope: Saved Data Guide answers use approved client-facing feature guidance and saved workspace data only. It does not use private operational documentation for client answers.

Vault Safety: Vault-area access by itself never reveals a password. Reveal and fill require the right permission plus an explicit user action. Reveal, fill, edit, grant, revoke, and archive actions are permission-gated and audit logged; passwords are not rendered during normal page load.

Browser Extension: when enabled, the Vault browser extension uses Sign in with Pulse and explicit Open & Fill actions. Click Sign in with Pulse in the extension popup, choose the workspace on the secure Pulse page, then return to the extension. Pulse does not silently autofill, auto-submit, or persist passwords in extension storage. Extension availability depends on Pulse administrator approval. Setup guidance will tell you to select the browser-extension folder that contains the manifest file.

Package and Billing Flow: workspace admins can review package limits and request package changes or support. Public package pricing may show PKR as the billing currency with USD shown only as a reference estimate. Paid checkout/provider setup is operator-managed and is not documented in client setup instructions.

Upgrade / Support Flow: if a package limit blocks a task, use the package page or Support Tickets to request a review. Pulse keeps saved workspace data during billing or package restrictions unless an authorized operator performs a separate approved action.

Usage Limits: package limits may count accepted refreshes, PageSpeed refreshes, new saved proposals, exports, AI requests, websites, team members, or Vault items. If a limit is reached, Pulse shows a safe package/support message instead of deleting saved workspace data.

Billing Configuration: live billing is controlled by authorized Pulse operators. Client docs show readiness and behavior, not private payment configuration.

Access & Launch Safety: links are opened manually in a new tab with safe browser attributes and are not included in client reports or proposal exports. Use Access & Launch for non-secret launch URLs and external password-manager references.

Vault Safety: encrypted credentials are excluded from reports, proposals, exports, and assistant prompts. Secret values are decrypted only for authorized explicit actions and are never shown in normal GET page HTML.

Vault Readiness: Vault screens show safe configured/not-configured status only. Key management and rotation are owner-only operations and are not documented for client users.

Uptime and Browser UX Updates: Website Detail now uses more saved uptime history for its timeline and Browser UX Diagnostics render human-readable issue explanations, likely checks, developer tasks, and client wording.

Exports: PDF and Excel report exports use saved workspace data and selected report sections. CSV-style exports remain simple saved-data downloads where available.

Operator Readiness: operator-only readiness checks summarize safe status without showing private configuration or changing client workspace data.

Future Improvements: PulseWMS may add richer onboarding, package-change workflows, support attachments, and browser-extension improvements later. Future provider setup, payment setup, and key-management details remain owner-only.

8A. Client Roles & Permissions

Workspace access is permission-based. A user may be able to view websites but not refresh them, open saved reports but not export them, or view proposals without being allowed to create new ones.

This is why some buttons can be visible for one workspace user but hidden for another user in the same workspace. Hidden actions usually mean the current role, grant, or plan does not allow that step.

Removing users, changing role/grant settings, and other member-management actions stay limited to authorized workspace admins.

2B. Affiliate Program

PulseWMS Affiliate Program is user-based. If your user account is connected to an affiliate-eligible paid workspace/package, Pulse can create your affiliate profile and referral link. You do not need to personally buy another package if you are already eligible through an approved paid workspace.

Eligibility: free/Starter and other ineligible packages do not unlock affiliate links or payable commission behavior.

Where It Appears: users with an affiliate profile see an Affiliate Program link in the profile menu and can open their own affiliate dashboard with their referral link/code, referrals, commission totals, and payout requests for their own account only.

Referral Basics: the referral link/code identifies you as the referring affiliate. Pulse blocks self-referrals and keeps attribution in saved signup/session records rather than hidden client-side price logic.

Commission & Payout Status: commission approval and payout handling are currently manual/admin-reviewed. Client docs do not expose payout credentials, payment-provider setup, or automatic payout configuration.

4. Browser/Form/JavaScript Event Tracking

Recommended Action: investigate recurring server/submission failures first; normal validation warnings usually need no operational response.

9A. Form Error Monitoring

PulseWMS can save important public form failures such as server-side submission problems, blocked sends, or plugin-level mail failures when the tracker can safely detect them.

Normal required-field validation is intentionally not treated as a failure alert. The goal is to highlight real customer-facing submission problems, not every small validation message during typing.

When Pulse cannot read the exact visible message, it can still save a safe fallback error summary. The saved row helps your team confirm that something failed even if the original plugin wording varied.

PulseWMS detects visible or plugin-reported submission failures. If a form shows success but the site owner does not receive the email, check the website's SMTP or mail-delivery settings. A browser tracker cannot confirm inbox delivery after a successful submission.

9B. JavaScript Error Monitoring

PulseWMS can save safe JavaScript error details from the public website, such as the message, file, line, and browser context. These rows are saved Tracking evidence only; they do not create email or bell notifications by default.

A saved JavaScript error can explain why a form stops responding, why a button does not work, or why a layout behaves strangely on the public site.

Because the tracker uses safe browser data only, it does not capture passwords, hidden form values, cookies, or private admin content.

9C. Browser UX Diagnostics

Browser UX Diagnostics summarize lightweight browser-side issues such as broken images, layout overflow, slow interaction warnings, or other visible experience problems on the public site.

These are saved hints for faster triage. They help explain why a page may feel broken or awkward to visitors even when the page is technically loading. Browser UX hints stay as saved evidence only and do not create email or bell notifications by default.

If no saved UX evidence exists yet, PulseWMS will show a clear not-captured-yet state instead of inventing a score or issue list.

5. External Scanner

The scanner checks public data from outside the website. It can detect homepage readiness, sitemap and robots signals, page HTML, response headers, DNS records, email authentication records, tracking tags, visible phone numbers, call tracking providers, saved homepage PageSpeed data, and visible public error text.

Where Data Appears: External Scanner Summary, Performance Insights, Page Audits, Scanner Issues, DNS & Infrastructure, Tracking Stack, Security Headers, Search Visibility, Sitemap Health, and Broken Content / Visible Errors.

How To Test: click Refresh Site Data, wait for the saved scan status to complete, then review the saved scanner sections on Website Detail and authorized detail pages.

Scale & Safety: large websites may take longer. PulseWMS uses background jobs, page limits, timeouts, response caps, and request delays. PulseWMS never performs unlimited crawls.

Common Limitation: the scanner does not execute JavaScript, so client-rendered content or tags injected after load may not appear in saved page audits.

6. Background Scan Jobs & Progress

• Refresh Site Data creates a queued scan job and updates Website scan status.
• The page returns immediately and shows saved refresh progress.
• Background processing handles queued jobs outside the page request.
• If background processing is unavailable, scans stay queued and the progress bar remains in the queued state.
• If a scan stays queued, contact your Pulse administrator and avoid repeatedly starting duplicate refreshes.
• Duplicate queued or running scans are blocked per website.
• Cancel Scan is supported: queued jobs cancel immediately, running jobs cancel safely between scan stages.

Recommended Action: if a scan remains queued for too long, ask your Pulse administrator to check background processing health.

7. Website Detail Page

Website Detail shows saved database results only: health score, browser tracker status, scan status, DNS and infrastructure fields, page audits, scanner issues, broken content, recent form errors, and uptime history.

Dynamic Browser Security Evidence: Pulse may save capped public metadata from the installed tracker when a page adds suspicious scripts, iframes, hidden spam links, or spam-like metadata after load. It does not collect cookies, browser storage, form field values, passwords, tokens, or full page HTML.

Website Fixing Guide: Website Detail includes a zero-cost deterministic fixing guide generated from saved data only. It explains what issues mean, why they matter, how to fix them, and how to verify remediation without calling AI or triggering scans on page load.

Website Assistant: Website Detail now places the Website Assistant in the primary Overview position where System Alerts previously appeared. Saved Data Guide mode is default, zero-cost, and deterministic from saved scan data only. AI Assistant mode is optional and runs only when a user submits a question with AI mode selected.

Scan Progress Placement: scan queued/running/completed/failed/cancelled progress appears directly under the Refresh Site Data action area so scan status is visible immediately after the action is clicked, and refresh redirects return to that top progress panel.

Offline Assistant Agent v2: Website Assistant now uses a centralized deterministic knowledge base plus saved-data routing so feature questions map to the correct workflow guidance without unrelated DNS/top-issue fallback.

Unknown Question Safety: if a question is unclear or low-confidence, Saved Data Guide does not guess a random issue. It returns contextual suggested questions based on wording such as uptime, tracker, report/export, proposal, backup, DNS/email-auth, or speed/PageSpeed.

Practical Answer Format: Offline Assistant answers include actionable steps, common causes, verify steps, developer-task wording, client-friendly wording, and where to check in Website Detail. If saved evidence is missing, the answer explains limits and the next manual refresh step.

Knowledge Base Coverage: cards cover tracking, reports/exports, proposals, backups, uptime, DNS/email auth, SSL/domain, platform/hosting, page audits, search visibility, performance/PageSpeed, operations/docs, and common availability questions such as “why data is not showing.”

Report / Export Guidance: Offline Website Assistant can guide report creation and exports from Website Detail saved data. Report guidance explains View Client Report, Save Report (PDF), and CSV exports, and confirms report pages do not trigger new scans on open.

Assistant Mode Toggle: proposal AI and Website Assistant AI use separate controls. Saved Data Guide remains available in all cases.

Assistant AI Safety: no AI runs on page load, after scan completion, or during report/proposal/PDF/DOCX exports. AI calls are explicit-action only, capped with cooldown and soft usage limits, and offline fallback remains available if AI is unavailable.

Fallback Source Clarity: if optional assistant mode hits limits or availability errors, Pulse marks the response source as Saved Data Guide and explains that saved-data guidance is still available.

Rate-Limit Cooldown: after a temporary usage-limit response, Website Assistant temporarily cools down optional assistant mode and serves saved-data guidance.

Availability: if optional AI is unavailable, Saved Data Guide mode still answers from saved client-safe data.

Tracker Verification Intent: Saved Data Guide includes dedicated tracking-code verification help (Browser Tracker status, snippet validation, and /api/v1/ping/ checks) so tracker questions do not fall into unrelated DNS guidance.

Educational DNS Answers: why/what questions such as "why use DKIM" explain the purpose first; operational fix steps are used when the user asks how to fix/check/setup DNS records.

Tracker Install Guidance: Offline tracker answers now include placement guidance (global header/custom code injection, ideally before closing </head>) and avoid functions.php-based instructions.

AI Fallback Intent: when AI is unavailable or rate-limited, Website Assistant falls back to the same deterministic Saved Data Guide router while preserving the original question intent.

Saved Data Source: Saved Data Guide uses saved scan/monitoring database data only and does not call AI.

System Alert Placement: saved warning/alert context remains available in the Issues section and authorized detail pages rather than a separate primary System Alerts card.

Scan Intelligence Snapshot: Website Detail also shows a compact proposal opportunity snapshot (audited pages, likely core pages, blog count, page-type mix, and top opportunities) derived from saved scan data only.

Triage Tabs Layout: Website Detail uses a compact premium dashboard layout with a site identity header, health score summary, top action bar, KPI cards, and saved-data tab panels for Overview, Up & Down Time, Performance, AI / GEO, Audits, Security / Issues, DNS, Platform, Tracking, and Reports. Compact tab spacing keeps the desktop tab bar on one line where space allows, and old #issues links still work. Only the active tab panel is shown, and each panel reads saved database sections only; they do not run live checks, uptime checks, DNS lookups, PageSpeed API calls, or scanner jobs during page load.

Tab Focus: Overview stays high-level, Up & Down Time keeps its full label and contains saved uptime logs, Performance contains saved homepage PageSpeed results, Audits stays page-level, DNS remains separate from Platform, Tracking contains browser/form/JavaScript event context, Security / Issues groups saved security and issue evidence, and Reports contains saved-result exports.

Header and KPIs: the Website Health score appears in the header as a score out of 100. Lower KPI cards avoid repeating Website Health and summarize other saved signals such as uptime, tracker, scan status, performance (saved mobile/desktop PageSpeed), CMS/platform, and HTTPS/SSL. Search Visibility remains in detailed evidence panels and history.

AI Search Readiness / GEO: Website Detail includes a dedicated saved-data tab with score, grade/status, top summary cards, page-wise readiness table, saved-data AI Search simulation preview, citation/authority gaps, AI Agent Readiness, Heading Structure + URL-Level Intelligence, and practical page suggestions. It uses saved scan data only; no optional assistant, PageSpeed, live GEO scan, citation API, directory lookup, backlink check, Google/provider call, or external request runs during page load. Saved detector evidence now feeds GEO visibility where available, so "Not checked yet" is limited to signals with no saved data yet. GEO history snapshots remain deferred until an explicit snapshot feature is approved.

Market-Growth Overview: Website Detail includes Client Health Score, Before / After Improvement Proof, and Form Monitoring cards. These cards use saved database rows only and show empty states when there is not enough saved evidence.

Top Actions: Refresh Site Data, Cancel Scan (when queued/running), View Tracking Code, Run Uptime Check Now, View Client Report, and Save Report stay visible above the tabs. Refresh Site Data still queues a ScanJob, remains available regardless of the active tab, and the uptime check remains separate from the full scanner.

Selective Refresh Checks: Website Detail Refresh Site Data can choose URL discovery, page auditing, DNS, SSL/domain, platform/hosting, tracking stack, and PageSpeed. Skipped checks keep previous saved results, so a PageSpeed-only refresh can avoid overwriting saved crawl/audit data. Proposal Prepare Latest Proposal Data still queues a complete scan by default.

Optional checks: the Refresh Site Data area includes an Optional checks dropdown so you can see that extra checks expand only when you choose them. Opening Website Detail does not run those checks automatically.

Saved Detector Evidence: Page Audits, Page Audit History, and Tracking can show compact saved evidence such as schema, JSON-LD, Microdata, RDFa, GTM, GA4, Meta Pixel, Google Ads/linker, forms, ecommerce, local proof, call tracking, WhatConverts, common marketing pixels, chat or booking widgets, and content depth. Pulse shows short labels instead of raw page code.

Malware & Injected Code Evidence: Website Detail summarizes saved public security-review evidence in the Security / Issues tab from scans, such as SEO spam/page takeover evidence, hidden spam links, suspicious external SEO infrastructure, schema or metadata hijack, insecure mixed-content assets, suspicious script evidence, injected-code indicators, hidden or insecure embeds, suspicious outbound-link wording, and saved content-change signals. Pulse tracker scripts are hidden from user-facing malware/security evidence as internal monitoring, and common embeds such as maps or videos are normal inventory unless they are hidden or insecure. This section is platform-agnostic review guidance, uses wording such as injected code evidence and possible defacement evidence, does not make confirmed malware claims, is not server-file antivirus, and only reflects crawled public pages within scanner limits. When SEO spam/page takeover evidence exists in current saved scan evidence or saved page title/meta/heading fields, Pulse leads with an action summary for affected pages, top URLs, main indicators, cleanup status, likely source hints, and next actions. Zero-count cards are hidden by default behind a Show empty categories control. The cards include short explanations and a View saved evidence details control; fresh saved scan indicators can show page URL, matched rule, source location, capped sanitized snippet, confidence, false-positive notes, and suggested action, while older saved rows may show a legacy-detail note. The main SEO spam detail panel groups the full incident by affected page with verdict, occurrence counts, hidden-link counts, schema/metadata groups, external infrastructure domains, inference-only source hints, and next actions. Related subcategory panels stay focused: cleanup details show cleanup hints, hidden-link details show hidden-link samples, schema details show schema/metadata groups, and external infrastructure details show domains and where they appeared. Repeated evidence is collapsed in the UI/report presentation while saved scan evidence remains available internally. Known vendor scripts such as GTM, GA, Hotjar, Bing, and Cloudflare/cdn-cgi/security challenge scripts stay inventory or lower-priority review evidence unless stronger unrelated compromise evidence exists; they do not keep cleanup marked incomplete by themselves. Cleanup verified requires a fresh explicit Refresh Site Data scan after cleanup with no current high-confidence SEO spam/page-takeover evidence. Long samples stay hidden until a user opens the saved-detail panel. External dependency inventory and operational signals remain in their own saved-data sections instead of the Malware section. Security Headers stay separate, and opening the page or detail panel does not run a scan, AI task, PageSpeed check, provider call, or email. High-confidence saved scan evidence creates or reuses one top-level Notification Center alert row for review; this batch does not add a new risk email path.

Website Health explanation: Website Detail now explains that the main Website Health score uses saved performance, SEO/page-audit, security/DNS, tracking, uptime, and forms/UX signals. AI Search / GEO readiness is shown separately.

Saved Data Guide coverage: Saved Data Guide can now answer common questions about saved detector evidence, why GEO may say not checked yet, how Website Health is calculated, why Google data may be missing, and what to fix first from saved evidence.

Compact Top Cards: PageSpeed helper copy lives in Performance Insights rather than the top KPI cards so Website Detail stays scannable.

Notification Links: notifications that can be matched to a saved website open Website Detail and the closest relevant section; generic notifications remain plain text.

Notification Center: the bell badge shows the exact unread count for the current shell or workspace scope. The bell dropdown includes a View All link to the full notification center at /notifications/, but the dropdown itself is only a short latest-unread preview. The center keeps both unread and read items with safe detail links and current-shell filtering, and read rows remain visible in history after acknowledgment.

Scan Architecture Safety: Proposal refresh uses the same ScanJob flow as Website Detail Refresh Site Data. Website Detail GET, reports, exports, proposals, and Website Assistant do not queue scans during page load/render.

Unknown States: values like HTTPS Available: Unknown or Possible DNS Provider: Unknown mean Pulse could not confirm those signals from the latest saved public scan; unknown does not always mean broken.

Browser UX Empty State: when no saved browser UX payloads exist yet, Website Detail shows a tracker guidance message instead of an empty diagnostics card.

Timezone: dashboard times should be interpreted in the configured/user timezone. VPN or IP changes should not be used as the primary timezone source. A future improvement can use a user profile timezone or browser timezone preference.

Safe Page Load: opening Website Detail reads saved rows only. To update data, use explicit actions such as Refresh Site Data or Run Uptime Check Now.

10A. AI Search / GEO Readiness

The AI Search / GEO area is a saved-data readiness view. It summarizes whether a website looks easier or harder for AI-driven answers and modern search experiences to understand.

This view can include saved AI Agent Readiness, crawlability, content clarity, technical trust, local/business trust, heading structure, URL intelligence, and other saved signals when they exist.

Opening this area does not run live AI checks, live Google searches, citation tools, backlink tools, or optional assistant providers. It stays saved-data only unless an explicit future action is approved.

7A. Client Reports & Exports

Each Website Detail page includes Reports & Exports actions for client-ready sharing. View Client Report opens a clean report with the executive summary, key findings, uptime, saved PageSpeed summary when available, DNS & Infrastructure, domain registration, platform/CMS detection, hosting signals, page audits, tracking stack, Malware & Injected Code Evidence, recommendations, and limitations.

Save Report: downloads a PDF report generated directly from the latest saved database results. PDF generation does not run scans, uptime checks, DNS lookups, browser tests, or other external checks. The HTML client report remains printable as a fallback for users who want a browser print view.

CSV Exports: Summary CSV uses readable website, date, status, DNS/email-auth, domain, platform/CMS, hosting, and saved issue-count columns. Page Audits CSV uses consistent page URL, HTTP, response-time, tracking, SSL, index/follow, visible-text, and broken-content columns. Issues CSV uses severity, category, title, message, affected URL, recommended action, and last seen/scanned.

Saved Results Only: client reports and exports read the database. The report does not run new scans, uptime checks, DNS lookups, or browser event tests during page load/download.

Hidden Report or Export Buttons: if View Client Report, PDF, CSV, or other export actions are missing, your workspace role, granted access, or current plan may allow view-only access without exports.

Refresh First If Needed: reports use the latest saved scan, tracker, uptime, and report rows. Run Refresh Site Data first when you need newer evidence before sharing.

Limitations: reports are based on public checks and browser tracker data. PulseWMS does not log into WordPress/admin/server, inspect hidden plugins/themes, or read private files.

How To Test: open Website Detail, click View Client Report, verify sections render, use Save Report, and download Summary, Page Audits, and Issues CSV files. Confirm downloads require login and do not trigger scanner helpers.

Report Section Controls: Website Detail report actions can include/exclude client report sections before viewing or downloading PDF. Reports and downloads still use saved database results only.

Hidden Report or Export Buttons: some report/export buttons may be hidden if your workspace role or current plan does not allow that action. Hidden buttons do not mean saved data was deleted.

Executive Summary: Client Report starts with Executive Summary, What changed, What we recommend, and What we will verify next. These points are generated from saved Pulse evidence and are included in report exports when the overview section is selected.

Market-Growth Summary: Client Report includes saved-data Client Health Score, Before / After Improvement Proof, and Form Monitoring sections when those report sections are selected. Form Monitoring summaries sanitize likely submitted values and do not include visitor-entered field data.

Saved Detector Evidence: after Refresh Site Data completes, reports and proposals may show compact saved evidence such as schema format, analytics/tag presence, form tracking hints, ecommerce/cart or checkout hints, local proof hints, common marketing/chat/booking/call-tracking labels, content depth, and indexability. These sections use saved results only and do not include raw page code, form entries, passwords, tokens, or provider secrets.

Malware Evidence In Reports: when saved risk evidence exists, HTML/PDF/DOCX/Excel reports can include plain-English sections for injected code and script evidence, mixed content / insecure assets, hidden or insecure embeds, suspicious outbound links, possible defacement evidence, and recommended review actions. These sections use saved evidence only and keep samples short and client-safe. SEO spam/page-takeover summaries are evidence-based review guidance, not server-file malware confirmation.

Saved GEO, Heading, and Google Evidence: the GEO / AI Search Readiness report section can include saved AI Agent Readiness, Page Audits can include saved Heading / URL Intelligence, and Google Data / Website Mapping can include saved Search Console performance only when the same workspace has a connected account, the website is mapped, and saved sync data exists. Google connection alone does not map every website automatically.

11A. Report Sections & Export Formats

Reports can include multiple saved-data sections such as executive summary, uptime, performance, DNS, page audits, tracking, AI Search / GEO readiness, Google data, and issue evidence when that information exists for the website.

PulseWMS can export reports in client-friendly formats such as on-screen report view, PDF, CSV/summary exports, and DOCX where enabled. Export buttons can be hidden when your role or workspace permissions do not allow exports.

Report pages and exports read saved website data only. They do not trigger a scan, Google sync, PageSpeed run, payment action, or external provider call when opened.

11B. Notification Center

The bell icon shows the unread notification count for your current shell or workspace scope. The small bell dropdown is only a quick latest-unread preview.

The full Notification Center keeps unread and read items together so you can review alert history. Opening the page on GET does not change notification state by itself.

Pulse no longer shows old Mark all read or Mark unread buttons there. The current flow keeps acknowledgment focused on the visible items you intentionally review.

Acknowledging notifications is an explicit action. Read items stay visible in history after acknowledgment so your team can trace what already happened.

11D. Workspace Access Security Snapshot

Workspace Settings includes a read-only Access Security Snapshot. It uses saved workspace members, pending invites, recent login dates, and login verification preferences to flag simple review items such as inactive admin access, old pending invites, many admin users, or admin users without recent login.

The snapshot is guidance only. Opening Workspace Settings does not send email, run scans, call outside providers, create tickets, or assign remediation tasks.

11C. Email Notification Preferences

Workspace users can have different email notification preferences. In-app notifications and email notifications are related, but they are not exactly the same thing.

Categories can include critical website alerts, form errors, uptime incidents, domain expiry alerts, and SSL certificate expiry alerts when those saved alerts exist for the current workspace. JavaScript errors, Browser UX hints, DNS warnings, and DNS record changes are saved for review, but they do not create email or bell notifications by default.

If you stop receiving expected emails, check your workspace notification settings first. Pulse sends form-error and uptime emails per eligible workspace recipient from saved alert conditions; simply opening pages does not send email.

11D. Google Data & Website Mapping

Google data is workspace-specific and website-specific. A workspace can connect approved Google accounts, then map each website to the correct saved Google property or location.

This mapping helps PulseWMS show saved Search Console, traffic, conversion, or local-performance context in the right website areas when that saved data exists.

Normal pages, reports, and proposals do not call Google on page load. They show saved data only until an authorized user runs an explicit connect, finish, sync, map, or disconnect action.

7B. Market Growth Insights

Client Health Score: combines saved PageSpeed, page audit, DNS/security, tracking, uptime, and form/UX evidence into a client-friendly score. If fewer than three categories have saved data, Pulse shows "Not enough data yet" instead of guessing.

AI Search Readiness / GEO: uses saved Website, PageAudit, PageSpeedResult, uptime, form, and browser UX rows to summarize crawlability/indexability, entity/content clarity, answer readiness, local/business trust, technical trust, experience/performance, measurement/tracking readiness, saved-data simulation estimates, and citation/authority gaps. The wording is readiness-signal guidance only and does not promise AI rankings or citations. Simulation and authority sections do not call AI, run live searches, check Google Business Profile/directories/backlinks/social profiles, or write history on page load.

Before / After: compares saved baseline and latest ScanJob/UptimeLog history to show improvement proof. If a baseline is missing, Pulse asks users to run more scans to build history.

Form Monitoring: summarizes saved form, JavaScript, and browser experience evidence. Important form submission failures, including supported Contact Form 7 app-level failures, can create saved Form Error evidence and eligible email alerts from the central Pulse tracker script. Pulse does not collect or render submitted form field values.

Tracking History Filters: open Website Detail, choose Tracking, then View Details to filter saved history by Form Errors, JavaScript Errors, Browser UX, Tracking Snippet, or Saved Audit. The Dashboard Form Errors page uses the same active grouped form incidents, so repeated copies do not inflate the list. JavaScript and Browser UX rows remain saved evidence only and do not send email or bell alerts by default.

Client Explanations: Explain actions are explicit POST requests. Saved Data Guide responses use client-safe docs and saved website data; optional assistant explanations require package entitlement and usage budget before any external service work.

Website Change Detection: Detect Saved Changes compares saved scan/audit rows and records safe events such as important URL status, noindex, title/meta, tracking, SSL, or form issue changes. It does not store sensitive page content.

Engagement Loop: Digest Preview, Top 5 Fixes This Week, and Recent Improvements use saved data only. Website Detail does not create tickets directly; support ticket creation stays in the client Support/Tickets flow. Email delivery requires SMTP configuration and no email is sent on page load.

Retention Reminders: the client top bar now includes an Actionable Follow-Ups panel with the current open count and the latest saved reminders, plus a View all follow-ups page for the full queue. Follow-ups can include stale scan, tracker, uptime, support ticket, Vault access review, and package-limit items from saved workspace rows. These reminders are guidance links only and do not run scans, email, billing-provider work, optional assistants, or PageSpeed during page load.

Safety: these insights read saved database rows only. They do not run scans, PageSpeed, optional assistants, SMTP/email, billing-provider work, or external calls on page load.

8. Dashboard Cards

Dashboard is a summary/triage page and reads saved database results only. The top area intentionally uses four priority cards: Website Health, Uptime Status, Tracking Status, and Critical Issues / Needs Attention.

Launch Checklist: workspace Admins and Managers can hide the Workspace Launch Checklist. The dismissal is saved for that user and workspace, so it does not affect other users or other workspaces.

Small Screens: wide dashboard and report tables may scroll sideways on phones or tablets so columns and action buttons stay readable.

After setup and retention summaries, the Monitored Websites table appears with search/filter/per-page controls. The table stays compact (Website, URL/domain, Browser Tracker, Scan Status, Last Scan, Actions) while Website Health remains on Website Detail and uptime remains in dedicated dashboard cards and Website Detail uptime sections. Lower-priority summary signals are grouped below the table into Search & SEO, Performance & Experience, Trust & Infrastructure, and Tracking & Forms so the top of the dashboard stays clean.

Small-Screen Tables: on phones and small tablets, wider tables may scroll sideways so headers and values stay readable instead of stacking into a confusing layout.

Navigation: the client sidebar item for client settings is Workspace Settings. Pulse operations remain restricted to the authorized Pulse operations team. Desktop users can collapse or expand the sidebar with the topbar button; PulseWMS saves that preference in the browser so the main workspace can widen when needed.

Recommended Action: use cards as triage links. Start with Critical Website Health, Failed External Scans, Uptime Down Sites, Broken Pages, and Search Visibility Warnings.

9. Uptime Monitoring

Uptime is an external check and is independent from Refresh Site Data, browser tracker status, and the full scanner. Refresh Site Data is not uptime monitoring.

Uptime vs Browser Tracker: uptime is a background availability check. It can report Up even when the browser tracker snippet is missing. Browser tracker status is a separate browser-side signal.

Automatic Monitoring: automatic down/recovery detection is managed by Pulse background monitoring. Run Uptime Check Now is only a manual one-off check.

Run Uptime Check Now on Website Detail is manual and creates a single saved uptime log. Automatic monitoring checks active websites in the background and does not require clicking the manual button.

Alerts: background monitoring keeps every saved uptime check row. During one active outage, Pulse reuses one downtime notification per recipient instead of flooding the Notification Center; repeated failed checks update that alert. Email reminders are limited to a 12-hour per-recipient policy, and a later successful check updates the same incident as recovered. Refresh Site Data is not uptime monitoring, and form/server errors are separate browser-event signals.

Where Data Appears: Website Detail has an Up & Down Time tab for saved uptime logs, an uptime vs downtime graph, latest uptime status, monitor guidance, and the manual Run Uptime Check Now action. The graph is based on saved uptime logs only and does not run checks during page load. The Overview tab keeps only high-level uptime summary cards.

9A. Performance Insights / PageSpeed

Google PageSpeed Insights is optional and configured by authorized Pulse operators. Private service configuration must never appear in UI, logs, reports, exports, or tests.

Safe Usage Policy: PageSpeed runs only inside explicit queued Refresh Site Data work. Default scope is homepage-only and default strategies are mobile + desktop. Website Detail, Dashboard, tabs, reports, proposal pages/exports, and Website Assistant all read saved PageSpeed rows only and do not call the API during normal renders.

Google Data Connections: workspace Admins can connect one or more approved Google accounts from Workspace Settings, then map each website to the correct saved Google account and property from Website Detail. Normal pages read saved Google summaries only. Connecting, finishing a connection, syncing, saving selections, or disconnecting are explicit button actions; reports and proposals do not call Google during page load or export.

Selective Refresh: PageSpeed can be unchecked in Website Detail Refresh Site Data when a faster or lower-quota refresh is preferred. Skipping PageSpeed keeps the previous saved PageSpeed result instead of clearing it.

Partial Result Behavior: if one strategy succeeds and another times out, Pulse saves the successful strategy as a partial result. This does not fail the full scan. Retry Refresh Site Data later to re-attempt the timed-out strategy.

Progress Notes: scan progress is stage-based and reflects saved job stages. Long PageSpeed stages may take longer because Google Lighthouse runs externally.

Unavailable: when PageSpeed is not configured, the scan stores a graceful not-configured status and continues. The UI shows a helpful empty or not-configured state.

Configuration: PageSpeed availability, strategies, and timeout policy are managed by authorized Pulse operators and are not shown as client setup commands.

Quota Safety: rate-limit or quota API responses are saved as safe status/error notes and the main scan continues. Deeper per-page PageSpeed checks are future-only and must be explicitly capped.

Saved Data: Pulse stores mobile and desktop Lighthouse category scores plus key metrics such as First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index when the API provides them.

10. Page Audits / Crawled Pages

PageAudit rows store URL, final URL, HTTP status, server response time, redirect count, SSL status, index/follow, title, canonical, meta description, Google tags, WhatConverts, tracking snippet, visible number, possible swap number, call tracking provider, broken content fields, visible text length, error signatures, best-effort page type, saved font-family signals, and last scanned time.

Website Detail and History Tables: the default Latest Crawled Page Data and Page Audit History columns focus on page-level results and include URL, Redirects, Server Response Time, Index / Follow, and Last Scanned. Optional table toggles include Title, Broken Content, Page HTTP, Page Type, Font Families, SSL, and saved detector evidence such as Schema, JSON-LD, Microdata, RDFa, Forms, GTM, GA4, Meta Pixel, Google Ads, Ecommerce, Local Proof, and Content Depth. Domain and provider details stay in the DNS & Infrastructure / SSL sections to avoid duplicate columns.

Page Type & Font Families: Page Type is a conservative platform-agnostic best-effort label such as Homepage, Page, Blog Post, Product, Collection, Category, or Unknown. Pulse uses strong public scan-time evidence such as schema and body classes, not URL slugs alone; when signals are weak or conflicting, it falls back to Page or Unknown. Font Families are detected from public HTML/style data during the queued scan with strict caps. These values are saved with PageAudit rows; Website Detail reads the saved database values only and does not fetch CSS or run font detection during page load.

Server Response Time: how long Pulse waited for the HTML response. It is not a full speed optimization or Core Web Vitals audit.

How Pulse Detects It: the scanner reads public HTML and headers from discovered public URLs and same-site homepage links, capped by scan limits.

Where Data Appears: Website Detail shows the latest saved rows; Page Audit History shows the full archive with optional columns.

Limitations: private pages, admin-only content, JavaScript-rendered tags, and pages blocked by robots or safety rules may not be scanned.

12A. Heading & URL Intelligence

Heading & URL Intelligence is part of the saved Page Audits story. It helps surface pages with weak headings, unclear page titles, repeated structures, or URLs that may be harder for visitors and search engines to understand.

These signals are practical editing clues, not automatic proof that a page is failing. They are most useful when paired with the page’s visible purpose, search intent, and conversion goal.

When this evidence is available, reports and proposals can reuse it in client-safe wording instead of repeating raw technical labels.

11. Broken Pages / HTTP Errors

Broken Pages identify public URLs that returned HTTP errors during the external scan. This matters because visitors, ads, search engines, and landing-page tests can hit these URLs even when the homepage looks fine.

Where Data Appears: dashboard Broken Pages / HTTP Errors cards, Scanner Issues, the Broken Pages & Visible Errors section, and Website History reports. Test by scanning a known missing page or a public test URL that returns one of these statuses.

12. Broken Content / Visible Errors

HTTP 200 does not always mean healthy. Pulse checks visible public HTML for phrases such as "There has been a critical error on this website", "Error establishing a database connection", "Briefly unavailable for scheduled maintenance", "Fatal error", "Parse error", "Warning:", "Maintenance mode", "Coming soon", "Under construction", "Service Unavailable", and "Gateway Timeout".

PulseWMS stores matched signatures, short evidence snippets, visible text length, and low-content signals. Visible Text Length is approximate public readable text after scripts/styles are ignored. Error Signature is a matched public error phrase, such as a database connection error or critical error. It does not store full HTML, server logs, screenshots, or WordPress admin data.

Possible Blank / Low Content Page: the page returned successfully but had very little visible text. This can be normal for some landing pages, but it may also mean content failed to load. Low content remains a warning unless paired with stronger error evidence.

Where Data Appears: Website Detail shows a combined Broken Pages & Visible Errors section with separate wording for Broken Pages / HTTP Errors and Broken Content / Visible Errors.

How To Test: create a public test page with a known phrase, run Refresh Site Data, wait for the refresh to complete, then check Broken Content / Visible Errors.

13. Search Visibility

Search Visibility can be Indexable, Discouraged, Noindex Found, Nofollow Found, or Unknown / Not Scanned. PulseWMS uses the latest completed scan of public page HTML, headers, robots.txt, and sitemap data.

Troubleshooting stale results: if WordPress or site settings changed, run Refresh Site Data and wait for background processing to complete. Cache/CDN layers may still serve old noindex HTML or X-Robots-Tag headers until purged.

Limitation: PulseWMS cannot read the private WordPress "discourage search engines" setting; it only sees public output.

14. robots.txt Checker

PulseWMS reads only the public /robots.txt file. This is a normal public file used to guide crawlers; PulseWMS cannot read backend files through it. robots.txt is not a security mechanism and can reveal public paths.

Pulse checks whether robots.txt exists, its HTTP status, sitemap lines, and broad Disallow: / rules. Missing robots.txt is usually informational. A full-site block is a critical search visibility signal.

How To Test: open /robots.txt on the public site, compare the file with Pulse’s saved robots.txt fields, then run Refresh Site Data after any change.

15. Sitemap Health

Pulse checks sitemap discovery, sitemap indexes, URL count, and discovered sitemap URLs with errors, noindex, or redirects. Scanner limits prevent unlimited sitemap crawling.

Why It Matters: sitemap problems can hide pages from discovery or surface URLs that should be redirected, restored, or removed. Missing sitemap data is useful context, not always an incident.

16. DNS & Infrastructure

PulseWMS stores nameservers, Possible DNS Provider, A/AAAA/CNAME records, TTL values, reverse DNS/PTR, Possible IP Owner, Possible Edge/CDN Provider, CAA, SOA, DNSSEC, and RDAP registrar/expiry fields when available.

Where Data Appears: Website Detail labels the combined area as DNS & Infrastructure / Email Authentication. The Email Authentication subsection shows MX, SPF, DKIM, and DMARC saved results.

When provider detection is not available, Pulse still shows Possible DNS Provider: Unknown, Possible Edge/CDN Provider: Unknown, and Possible IP Owner: Unknown. Unknown means public inference was unavailable; it does not always mean misconfiguration or outage. Provider detection is based on public DNS and HTTP header signals, and origin hosting may be hidden by a CDN/proxy.

DNS Change Evidence: DNS records and DNS changes stay saved in DNS & Infrastructure for review. Pulse does not send DNS-change email or bell alerts by default; DNS warnings, missing email-authentication records, and possible misconfiguration notes also remain saved evidence only.

How To Test: run Refresh Site Data, compare DNS & Infrastructure / Email Authentication with public DNS tools, and treat provider labels as possible when inferred from names or headers.

Limitations: public DNS only; origin hosting may be hidden by CDN/proxy; provider labels are "possible" when inferred from public names and headers.

16A. Domain Registration / Expiry

PulseWMS uses RDAP, a public domain registration protocol, during background scanner jobs to save registrar, created/updated/expiry dates, domain statuses, source, and lookup errors when available.

Where Data Appears: Website Detail shows Domain Registration / Expiry inside Platform & Hosting, while Client Report and Summary CSV include the same saved fields.

Limitations: expiry may be unavailable for some TLDs or registrars. PulseWMS does not log into registrar accounts, scrape random websites, or use paid APIs. Unknown is normal and is not critical by itself.

16B. Platform / CMS Detection

PulseWMS is platform-agnostic. The one-line browser tracker can work on WordPress, Shopify, Wix, Squarespace, Webflow, WooCommerce, BigCommerce, Magento/Adobe Commerce, Drupal, Joomla, HubSpot CMS, and custom sites when installed in public pages.

Platform detection uses passive public HTML, headers, scripts, cookies, and asset URL signals only. If the platform is not visible publicly, Pulse shows Unknown.

Where Data Appears: Website Detail groups Platform / CMS Detection, Public Technology Signals, Hosting / Infrastructure Provider, and Domain Registration / Expiry under the Platform & Hosting tab so these signals stay separate from DNS records, SSL, and email authentication.

Not Included: no CMS/admin login, no private app/plugin controls, no private platform API access, and no aggressive platform probing.

16C. Public Technology Signals

PulseWMS shows CMS-agnostic public technology intelligence from saved passive signals. WordPress theme/plugin/version values, Shopify storefront markers, Wix/Squarespace/Webflow builder signals, Drupal/Joomla/Magento paths, and backend/runtime headers appear only when the saved public evidence exposes them. Hosted SaaS platforms such as Shopify, Wix, Squarespace, and Webflow may show Managed platform runtime because their backend runtime is not normally public.

Where Data Appears: Public Technology Signals appear as a sub-section inside Platform & Hosting, not as a separate main tab. Unknown means the value was not publicly visible in saved data; it does not prove the technology is absent.

Limitations: hidden apps/plugins, inactive extensions, private versions, server-side details, and complete app/theme inventories cannot be listed without admin/vendor access. PulseWMS avoids brute-force enumeration.

16D. Hosting / Infrastructure Provider Detection

DNS provider, hosting provider, CDN/edge provider, IP owner, ASN/network owner, and registrar are different things. Pulse infers possible hosting only from public DNS, CNAME, reverse DNS/PTR, IP owner, response header, and platform signals.

Limitations: Cloudflare or another proxy can hide the origin host. Unknown is normal when public signals are hidden, and PulseWMS does not claim exact hosting unless evidence is strong.

17. DNS & Email Authentication

18. Security Headers

Pulse checks HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy. Statuses are Good, Partial, Weak, or Missing, with present/missing/weak values shown in page audits.

Website Detail also shows HTTPS Available, SSL Certificate, and SSL Expiry Days. For HTTP websites, Pulse checks the HTTPS version during the external scanner job to see whether SSL is available, without changing the saved URL. If HTTPS Available is Unknown, it means Pulse could not confirm it from the latest saved public scan and does not always mean HTTPS is broken.

How Pulse Performs It: the external scanner reads response headers from public pages and summarizes the values saved in Page Audits.

Recommended Action: treat missing or weak headers as hardening work unless paired with an active incident.

17A. Domain Expiry Alerts

Domain expiry alerts use saved domain registration data, including saved days-until-expiry values when available. PulseWMS does not need to open your registrar account to show those saved reminders.

If expiry information is unavailable for a domain, Pulse shows that the saved data is missing instead of inventing an alert date. No live registrar lookup runs just because you opened a page.

These alerts help teams act before a domain gets too close to expiry, especially when a workspace manages multiple client sites.

18A. SSL Expiry Alerts

SSL expiry alerts use the latest saved SSL certificate evidence from prior checks. PulseWMS can show when a certificate is approaching expiry without running a fresh live TLS lookup during page view.

If no saved SSL evidence exists yet, the alert area stays in a not-available state instead of guessing a certificate date.

These alerts are meant to help teams renew or verify certificates early, especially before an avoidable trust or availability problem becomes client-visible.

18B. Tracking Provider Labels

The Tracking area can show provider labels for common marketing and UX tools when they are visible in saved public evidence. This can include Google tags plus providers such as Meta Pixel, Hotjar, Microsoft Clarity, HubSpot, Calendly, Intercom, LinkedIn, TikTok, CallRail, and other common browser-side tools when detected.

A missing provider label does not always mean the tool is absent. Some providers are loaded only after consent, after login, or through patterns that are not visible in saved public evidence.

Provider labels are there to speed up investigation and reporting. They do not confirm billing setup, campaign quality, or account ownership by themselves.

19. Tracking Stack / Google Tags / WhatConverts / Swap Numbers

Pulse detects the Pulse tracker, Google Tag Manager IDs beginning with GTM-, GA4 IDs beginning with G-, Google Ads IDs beginning with AW-, legacy UA- IDs, WhatConverts, CallRail, dynamic number insertion, and DNI phrases.

Google tags are counted only from reliable Google script/config contexts such as googletagmanager.com/gtag/js?id=, gtag('config', ...), GTM container URLs, AW IDs, and UA IDs. Random visible text that looks like G-HOME is ignored.

Visible Number means a public phone number was found. Possible Swap Number means a number appears with call tracking signals. Confidence is confirmed, possible, or not detected.

Limitations: tags inserted only after JavaScript execution may not appear to the external scanner. Confirm critical marketing tags in the provider tools when Pulse shows possible or not detected.

20. Site Health Score

The score is out of 100 with statuses Good, Needs Attention, Critical, and Not Enough Data. Factors include uptime, tracker detection, critical HTTP errors, search visibility, sitemap/robots signals, SSL, response time, and broken content.

Where Data Appears: Website Health Overview, Website Detail, and filtered dashboard lists. Run uptime plus Refresh Site Data to move from Not Enough Data to a calculated score.

21. Critical Alerts

PulseWMS uses severities such as Critical, Warning, Notice, and Passed. AlertEvent records prevent duplicate alert spam for the same unresolved fingerprint. Recovery handling can resolve and reopen events when the same issue returns.

Packages and annual pricing: PulseWMS packages are shown as Starter, Launch, Agency, Agency Pro, and a separate Reseller / White-Label plan. Public package cards can show PKR as the primary billing price, with USD only as clearly marked reference copy. Annual pricing shows the yearly total, monthly equivalent, and savings label from the saved package discount. Workspace package requests stay explicit actions and page loads do not contact payment providers.

Reseller selling: Reseller-plan agency workspaces can maintain agency-branded package names, monthly prices, and annual discount percentages, assign one package to a client workspace, and show that read-only package summary inside the client workspace. Authorized reseller Admins and Managers get a direct Reseller sidebar link as well as the Workspace Settings card. Assignment by email never links to another agency’s client workspace. Reseller agency workspaces are named from the agency or business name entered during signup; Google sign-in users finish that agency-details step before the reseller workspace is created. An existing Pulse account receives access only to the newly assigned client workspace; old removed workspaces are not restored. Re-saving an active package updates that assignment instead of adding another active package. Billing / Upgrade includes an Add another workspace/package link that opens the saved package-selection flow without starting a payment on page load. Reseller branding can add an agency brand name, public logo URL, colors, and support label to client-ready reports and eligible form/uptime alert emails. Read-only report share links are created and revoked by explicit actions, and shared viewers do not get workspace controls. This is manual/internal billing only: PulseWMS does not automatically charge clients, and Pulse internal, wholesale, or reseller-plan cost details are not shown to clients.

Malware & Injected Code Evidence: package availability is based on saved public scan evidence. It is review guidance, not guaranteed malware removal or server-file antivirus.

Email Behavior: local development may print email to console; production needs configured email settings and notification preferences.

22. Admin User Management

Client Admins can edit workspace members, assign roles, grant Vault page access, and remove members. Pulse protects the last workspace Admin; profile pages hold notification and password controls.

23. Security & Load Safety

• Safe URL validation blocks private/internal targets, unsafe ports, credentials in URLs, and unsafe redirects.
• Central safe HTTP helpers enforce timeouts, response size caps, redirect limits, allowed content types, request delays, page limits, and sitemap limits.
• robots.txt is respected by default for discovered crawl URLs.
• PulseWMS does not execute JavaScript, crawl without limits, collect form fields, or require a website plugin.
• The browser tracker redacts sensitive query parameters before sending page URLs.

24. Testing Guide

25. Troubleshooting

26. Limitations

• No WordPress plugin, private admin data, file integrity scanning, or server log access.
• Public scanner sees public HTML and headers only; JavaScript-rendered content may be missed.
• DNS provider, CDN provider, and mail provider detection is inferred from public records and headers.
• DKIM checks common selectors only.
• RDAP registrar/expiry may show Unknown when public RDAP data is unavailable or incomplete.