INTERNAL — NOT FOR DISTRIBUTION
Web Relevant Playbook
WR / OPS — OPERATIONS FIELD MANUAL
"It is easy to be brave from a safe distance."
— Aesop
ASSESS
Understand before acting.
Identify the actual problem, dependencies, ownership, access, and desired outcome before making changes.
PRESERVE
Protect the known-good state.
Capture enough of the current configuration, content, access, and evidence to compare or recover if the change fails.
CHANGE
Make the smallest deliberate change that solves the problem.
Avoid unnecessary variables so the effect of each action remains understandable and reversible.
VERIFY
Prove the outcome, not the action.
Test that the system actually works as intended, including dependencies the change could have affected.
ASSESS
Understand before acting.
Identify the actual problem, dependencies, ownership, access, and desired outcome before making changes.
PRESERVE
Protect the known-good state.
Capture enough of the current configuration, content, access, and evidence to compare or recover if the change fails.
CHANGE
Make the smallest deliberate change that solves the problem.
Avoid unnecessary variables so the effect of each action remains understandable and reversible.
VERIFY
Prove the outcome, not the action.
Test that the system actually works as intended, including dependencies the change could have affected.
DNS / Domain
BEFORE DNS CHANGES
- Export the current DNS zone file and retain it as the point-in-time rollback baseline.
- Record the expected DNS record count.
- Identify critical MX, SPF, DKIM, DMARC and third-party verification records.
- Confirm domain ownership, registrar, nameservers and access before changing anything.
AFTER DNS CHANGES
- Verify website resolution.
- Verify www and root domain behavior.
- Verify email send and receive.
- Verify critical third-party services.
- Compare records against the pre-change baseline if anything behaves unexpectedly.
ROLLBACK
- Use the saved zone-file export as the restoration baseline when appropriate.
- Do not assume an import alone completed recovery.
- Verify record count, website, email and dependent services after restoration.
BEFORE CHANGES
- Confirm current mail provider, MX records, and SPF/DKIM/DMARC configuration.
- Identify all mailboxes, aliases, and distribution lists in scope.
- Confirm organizational ownership of the email domain.
PROVISIONING / MIGRATION
Checklist to be added when procedures are established.
VERIFICATION
- Send and receive test messages from affected accounts.
- Verify MX, SPF, DKIM, and DMARC records resolve correctly.
- Confirm no mail is queued or bouncing.
Website Launch
PRE-LAUNCH
- Confirm domain ownership, registrar access, and DNS control.
- Identify current hosting and any active redirects.
- Confirm SSL certificate provisioning plan.
- Verify all content, links, and forms before cutover.
PRESERVE — BEFORE WEBSITE MIGRATION OR FAILOVER
- For an established website, review Google Search Console before replacement when access is available.
- Identify currently indexed URLs and recent page performance.
- Use this evidence to determine which legacy URLs should be preserved, rebuilt, permanently redirected to a relevant replacement, or deliberately retired.
- Do not blindly redirect unrelated old URLs to the homepage.
CUTOVER
Checklist to be added when procedures are established.
POST-LAUNCH VERIFICATION
VERIFY THE REPLACEMENT, NOT JUST THE CUTOVER.
Publishing or changing DNS proves that a change was made. Verification means confirming the replacement website and its important dependencies actually work from the outside.
- Verify www and root domain resolution.
- Verify SSL is active and certificate is valid.
- Verify contact forms and critical integrations.
- Confirm old URLs redirect correctly if applicable.
POST-OP / VERIFY — GOOGLE SEARCH CONSOLE
- Preserve the existing Google Search Console property and ownership verification whenever possible. Do not create a new property merely because the website platform changed.
- Prefer existing DNS/domain ownership verification when available.
- Resubmit the live production sitemap in Google Search Console.
- Use URL Inspection on the canonical homepage and run Test Live URL.
- Confirm page fetch succeeds, crawling is allowed, indexing is allowed, HTTPS works, and the user-declared canonical points to the intended production URL.
- After the live test passes, use Request Indexing for the changed homepage.
- Do not repeatedly request indexing. Allow Google to process the sitemap and priority crawl request.
Airo / Search Console note: Airo's built-in Search Console connection is optional. If an established domain already has a working DNS-verified Search Console property, do not replace or disturb that verification merely to make Airo report Search Console as connected. Search Console and sitemap management can be handled directly through Google.
Website Down
INITIAL ASSESSMENT
- Confirm the outage is not local (test from a second network or device).
- Identify whether DNS, hosting, or the application is the failure point.
- Check domain expiration and hosting account status.
- Check for recent DNS or configuration changes.
ESCALATION / RESOLUTION
Checklist to be added when procedures are established.
VERIFICATION
- Confirm resolution from multiple networks.
- Verify SSL, forms, and critical integrations.
- Document root cause and corrective action.
Account Access
INVENTORY
- Identify all accounts in scope (domain, hosting, email, vendors, listings).
- Confirm which accounts are tied to personal vs. organizational credentials.
- Identify accounts with no current organizational access path.
RECOVERY / TRANSFER
Checklist to be added when procedures are established.
VERIFICATION
- Confirm organizational login works for each recovered account.
- Update recovery email and phone to organizational contacts.
- Document account landscape after changes.
Employee / Officer Change
BEFORE DEPARTURE
- Identify all accounts, systems, and vendor relationships tied to the departing person.
- Identify accounts registered to personal email addresses.
- Transfer ownership and update credentials before the transition date.
- Document responsibilities for the incoming team.
AFTER DEPARTURE
- Confirm no active access remains on personal credentials.
- Verify critical services are uninterrupted.
- Update organizational contact records with vendors and registrars.
VERIFICATION
Checklist to be added when procedures are established.
Passwords
No passwords, credentials, MFA codes, or recovery codes are stored in this document.
PRINCIPLES
- Credentials belong to the organization, not to individuals.
- All critical accounts should use organizational email addresses as the login.
- Recovery options (backup email, phone) should be organizational, not personal.
- Access should be revocable without disrupting the service.
ROTATION / RESET
Checklist to be added when procedures are established.
Vendors
INVENTORY
- Maintain a current list of active technology vendors and subscriptions.
- Record the organizational contact, login, and billing method for each.
- Flag any vendor accounts tied to personal credentials.
ONBOARDING / OFFBOARDING
Checklist to be added when procedures are established.
VERIFICATION
- Confirm vendor list is current after any staff or system change.
- Verify billing is on an organizational payment method.
Files
INVENTORY
- Identify where critical business files are stored (cloud, local, shared drives).
- Confirm organizational ownership of storage accounts.
- Identify files stored only on personal devices or accounts.
ACCESS / MIGRATION
Checklist to be added when procedures are established.
VERIFICATION
- Confirm critical files are accessible to the organization independent of any one person.
- Verify backup or redundancy for critical documents.
BC / DR
PREPAREDNESS
- Identify critical systems and the impact of each going down.
- Confirm organizational access to all critical accounts and systems.
- Identify single points of failure (one person, one device, one credential).
RESPONSE
Checklist to be added when procedures are established.
RECOVERY VERIFICATION
- Verify each critical system is operational after recovery.
- Document what failed, what was done, and what remains.
Troubleshooting
BEFORE ACTING
- Reproduce the problem on a second device or network before concluding it is systemic.
- Identify the most recent change made before the problem appeared.
- Preserve the current state before making any corrective change.
DURING
- Change one variable at a time.
- Document each step taken and its result.
- Do not assume a change worked — verify the specific symptom.
AFTER
- Confirm the original problem is resolved.
- Confirm no secondary problems were introduced.
- Document root cause and corrective action.
Internal use only. No credentials, client data, or confidential information in this document.