Post-launch Cleanup — First-week operations after going live

How to verify, monitor, and stabilize a new SGEN site in the seven days after launch

The moment Maintenance Mode goes off and the public URL is live, the site shifts from a build project to an operating system. Most teams experience the same first-week surprise: the launch itself goes fine, but the week after reveals gaps that the pre-launch checklist could not catch — analytics receiving data but not attributed correctly, a form submission routing to an inbox nobody monitors, an Activity Log flagging an error that started on day one. This guide walks six checks to run in the first week. Each check has a clear signal for "this is working" and a short remediation path for "this is not."

What is this for?

This is the post-launch, first-week operations sequence for a new SGEN site. Use it after the site is live and receiving real traffic. It picks up where the SGEN Pre-launch Checklist ends. That checklist gets the site to launch-ready. This guide gets the site to stable operations.

The six checks are:

1. Verify analytics is receiving and attributing data correctly.
2. Confirm search indexing is active and the sitemap is submitted to Google Search Console.
3. Test form submissions end-to-end through the real delivery path.
4. Confirm SSL and HTTPS are active across every page.
5. Set up the first scheduled.sgen backup.
6. Review the Activity Log for any error noise from the first days of live traffic.

None of these require technical access beyond the SGEN admin panel. No code changes. No server access.

Good use cases

• The site launched this week and you want to confirm everything is operating cleanly.
• A client went live this week and you want a structured first-week handoff checklist.
• You are onboarding a new operator to take over a live site and need a structured orientation to the operational surfaces.
• You suspect something is off in the first week — analytics looks wrong, a form submission went missing — and you want a systematic place to start.
• You are running a post-launch review meeting and want a structured agenda.

What NOT to use this for

• Pre-launch preparation — use the SGEN Pre-launch Checklist instead.
• Ongoing weekly or monthly site audits — the Activity Log and Site Vitals are the surfaces for those, and they have their own guides.
• Troubleshooting a site that was working and then broke — the Activity Log guide is the right starting point for regression investigation.
• Setting up new features or modules — this guide covers the six operational checks only.

How this connects to other features

• SGEN Pre-launch Checklist — the 23-step sequence that runs immediately before this guide.

The Pre-launch Checklist ends when Maintenance Mode goes off; this guide starts at that moment.

• Backup and Restore — Check 5 in this guide schedules the first backup.

The Backup and Restore guide covers the full schedule options, retention settings, and restore procedure.

• Activity Log (in your SGEN admin) — Check 6 in this guide reviews the first days of Activity Log entries.

The Activity Log guide covers filtering, exporting, and interpreting persistent log patterns.

• Google Search Console integration — Check 2 in this guide submits the sitemap.

The GSC integration is configured in Tools → Google Integrations; that surface is also where Analytics lives.

Before you start

You should have:

• A live SGEN site with Maintenance Mode off.
• The Google account connected to the site's Analytics and Search Console properties.
• Access to the inbox or CRM that receives form submissions.
• The SGEN admin open at /sg-admin/.

If the site has not launched yet, run the SGEN Pre-launch Checklist first and return here when Maintenance Mode is off.

Where to find it

The six checks touch five areas of the SGEN admin:

• Live Analytics — Dashboard → Live Analytics
• Google Integrations — Tools → Google Integrations
• Forms — Modules → Forms → (your form) → Notifications
• SSL status — Site Settings → General → Domain (or dashboard indicator)
• Backup and Restore — Tools → Backup and Restore
• Activity Log — Tools → Activity Log

Keep this page open in a second tab while you work through the admin.

Steps

Run the six checks in order. They are independent — you can do them in any order if a specific one is urgent — but the order below reflects the signal-strength of the checks. Analytics and indexing give the fastest confirmation that the launch is working at infrastructure level. Forms and SSL protect trust. Backups and the Activity Log are the ongoing operational baseline.

1. Verify analytics is receiving data

Navigate to Dashboard → Live Analytics.

Open the public URL in a private browser window on the same device. Wait 30 seconds. Return to the Live Analytics panel. The visitor count should increment by at least one — your own private-window session.

If the count does not move, the Analytics connection is not receiving data. Check Tools → Google Integrations to confirm the Analytics property ID is saved correctly. If the property ID is there but data is still not arriving, confirm the Analytics property in Google Analytics itself is set to the correct measurement ID and is not filtered by internal IP.

A working analytics connection shows a non-zero active visitor count within 60 seconds of a real page load.

2. Confirm search indexing is active and the sitemap is submitted

Navigate to Tools → Google Integrations.

Confirm two things in this panel:

First, confirm the Search Console property shows as "Verified." If it shows "Not verified" or "Pending," the connection did not complete during the pre-launch setup. Re-run the verification step: Tools → Google Integrations → Search Console → Verify Site.

Second, confirm the sitemap was submitted. If the sitemap submission date is empty, submit it now. Copy the sitemap URL shown in this panel (typically https://<your-domain>/sitemap.xml) and paste it into Google Search Console → Sitemaps → Add a new sitemap. Google begins discovering pages within 24 to 72 hours.

Navigate to SEO → Global SEO and confirm "Enable search engines from indexing" is toggled on. This is the most common first-week miss: the indexing toggle was left off from the pre-launch setup.

3. Test form submissions end-to-end

Navigate to Modules → Forms.

Open each active form and check the Notifications tab. Confirm the notification email address is correct and that notification is set to "On every submission."

Then open the live site in a private window and submit a real test entry through each form. Use a real email address you can check — not a placeholder. Wait five minutes, then check the inbox or CRM the form is supposed to route to.

A working form submission leaves three traces:

• The submission appears in Modules → Forms → (form name) → Submissions with a timestamp.
• The notification email arrives in the configured inbox.
• If a CRM or webhook is configured, the lead appears in the external system.

If the submission appears in SGEN but not in the inbox, the notification routing is broken. Check the notification email address in the form settings, and check the SMTP configuration in Site Settings → Email. If the submission does not appear in SGEN at all, check the reCAPTCHA configuration — a misconfigured reCAPTCHA score threshold can silently block submissions.

4. Confirm SSL and HTTPS are active across all pages

Navigate to Site Settings → General.

Confirm the SSL certificate shows "Active" with an expiration date more than 30 days in the future. Confirm "HTTPS redirect" shows as enabled so that any HTTP traffic redirects to HTTPS.

Then open the live site in a browser and check the address bar. The padlock icon should show with no warnings. If the browser shows "Not Secure" or a mixed-content warning, one or more resources on the page (images, scripts, or stylesheets) are loading over HTTP instead of HTTPS.

To find mixed content, open browser developer tools → Console. Mixed-content warnings appear as errors listing the HTTP resource URL. In most cases the fix is to update the resource URL in SGEN to use HTTPS, or to re-upload the resource through the SGEN Media library, which serves assets over HTTPS automatically.

If the SSL certificate shows "Pending" more than 24 hours after the domain was bound, DNS propagation has likely not completed. Confirm the domain's A record at the registrar points to the correct IP address shown in Site Settings → General → Domain.

5. Set up the first scheduled backup

Navigate to Tools → Backup and Restore.

Before setting the schedule, run a manual backup first. Click "Run Backup Now." The backup file should appear in the backup list within two to five minutes with a .sgen extension and today's date.

After the manual backup completes, download a copy to local storage. A .sgen backup file stored only on the SGEN platform is not a complete disaster-recovery posture — the off-platform copy is what protects against platform-level incidents.

Then set the schedule. Weekly at 2 AM on Sunday works for most new sites. High-traffic or e-commerce sites should switch to daily. Set retention to at least five backups so you always have a month of weekly history.

For full backup options, schedule configuration, and restore procedures, see Backup and Restore.

6. Review the Activity Log for error noise

Navigate to Tools → Activity Log.

Filter the log to show only Errors and Warnings from the past seven days. Look for patterns — a single error is an event; the same error appearing 10 times per hour is a signal.

Common first-week error patterns and what they mean:

• SMTP delivery delayed — the outbound email queue is retrying.

Check Site Settings → Email and confirm the SMTP credential is still valid. Some providers rotate credentials; paste the current credential and save.

• Backup failed — the scheduled or manual backup did not complete.

Check disk quota usage in Site Settings → General. If the quota is near the limit, download and delete older backup files before the next run.

• Form submission blocked — reCAPTCHA rejected a submission.

If this appears frequently, the score threshold may be set too high. Lower it slightly in Tools → Google Integrations → reCAPTCHA → Advanced.

• Media file not found — a referenced image or file is missing.

Navigate to the page or post that referenced it and re-upload the file.

• Login attempts from unrecognized IP — normal for any public site.

If the volume is high (more than 10 per hour), check Users → Security and confirm strong passwords are set for all admin accounts.

If the Errors tab shows zero entries and the Warnings tab shows fewer than five entries per day of traffic, the site is operating cleanly. Return to the Activity Log at the end of the first week for a final review before declaring the launch stable.

For a full reference on Activity Log filtering, export, and persistent pattern analysis, see Activity Log (in your SGEN admin).

What success looks like

A stable first-week SGEN site shows all six checks passing:

• Live Analytics increments within 60 seconds of a real page load.

Search Console shows at least one sitemap submission and pages being discovered.

• Form submissions appear in the SGEN submissions list, arrive in the correct inbox, and do not trigger reCAPTCHA blocks for real users.
• The browser address bar shows a valid padlock on every page of the site, including any internal pages linked from the homepage.

No mixed-content warnings appear in the browser console.

• A completed .sgen backup file exists on the platform, and one copy is saved off-platform.

The backup schedule is configured and shows the next scheduled run.

• The Activity Log Errors tab shows zero recurring patterns.

Any isolated warnings have been investigated and are either resolved or noted as expected behavior.

When all six pass, the site is operationally stable.

What to do if it does not work

Analytics shows 0 visitors even with real traffic on the site. Open Tools → Google Integrations and confirm the Analytics property ID is saved. Open the live site in a private window, wait 60 seconds, and check Live Analytics again. If still 0, open the Analytics property in Google Analytics directly and confirm the Measurement ID matches what is in SGEN. A mismatch between the tracking ID in SGEN and the property in Google Analytics means data is being sent to the wrong property or not at all.

Search Console still shows "Not verified" after reconnection. The verification method used during setup may have expired. Re-run the verification from Tools → Google Integrations → Search Console → Verify Site. If verification fails again, use the HTML tag verification method in Google Search Console directly and paste the meta tag into Site Settings → SEO → Custom Header Tags.

Test form submission arrived in SGEN but not in the inbox. Confirm the notification email address is correct in Modules → Forms → (form) → Notifications. Check the site's SMTP settings: Site Settings → Email. Send a test email from Site Settings → Email → Send Test and confirm that arrives. If the test email arrives but form notifications do not, the form's notification trigger is misconfigured — check that notifications are set to "On every submission" and not "Never."

SSL shows Active but the browser still shows a warning. A mixed-content warning means a specific resource on the page loads over HTTP. Open browser developer tools → Console to find the flagged resource URL. Most common cause: an image uploaded before the domain was bound to HTTPS, with its URL hardcoded as HTTP. Re-upload the image through the SGEN Media library, which serves all assets over HTTPS.

Backup keeps failing. Check Tools → Backup and Restore for the error message. The most common cause is disk quota. Download and delete older backup files through the backup list. If quota is not the issue, check the Activity Log for the specific error and contact support with the log export.

Activity Log shows the same error repeating every few minutes. A repeating error is always worth investigating before the end of the first week — it compounds. Export the log (Activity Log → Export) and filter to the specific event type. Note the timestamp cadence. If the event fires on a regular interval, it is likely a scheduled task that is failing silently. Contact support with the exported log.

Examples

Three first-week scenarios operators encounter most often.

Example 1: Analytics receiving data but source attribution looks wrong.

An operator notices that Live Analytics shows visitors arriving but the Top Source column shows everything as "Direct" — even traffic that clearly came from a Google search. This is usually a UTM-parameter or referral-exclusion issue. Check Tools → Google Integrations and confirm the Analytics property ID is correct. Then open the Analytics property in Google Analytics → Admin → Data Streams → (stream) → Configure tag settings → List unwanted referrals. If the site's own domain is in the unwanted-referrals list, it is attributing all traffic as direct. Remove it and wait 24 hours for new sessions to attribute correctly.

Example 2: Form submissions arriving but routing to the wrong inbox.

A client calls to say a lead submitted through the quote form but nobody on the sales team received it. The operator opens Modules → Forms → Request a Quote → Notifications. The notification email shows the previous agency's account address. Update it to the client's sales address, save, and run another test submission to confirm. Check the SGEN submissions list to confirm the original submission is recorded so the lead is not lost.

Example 3: Activity Log shows a repeating SMTP warning.

The Activity Log Warnings tab shows "SMTP delivery delayed — retry queued" appearing every 15 minutes since launch. The operator opens Site Settings → Email, pastes a fresh SMTP credential (the original was created before launch and the provider rotated the app password), and saves. Sends a test email — it delivers. Returns to the Activity Log after 30 minutes; no new warnings. The backlog of queued notifications from the previous 12 hours delivers within the next hour.

Tips for the first week

• Check the Activity Log daily for the first seven days.

After the first week settles, weekly reviews are sufficient for most sites. The first week is when configuration gaps surface as real errors.

• Run one more backup at end of week one.

The scheduled backup covers ongoing operations, but a manual end-of-week backup creates a clean restore point before traffic patterns have time to create content drift.

• Test every form on the live site, not only the admin preview.

The admin form preview does not fire notifications. The test submission through the live site is the only confirmation that the delivery path works end to end.

• Compare Live Analytics to Google Analytics for attribution.

SGEN Live Analytics and Google Analytics use the same underlying data stream. If the numbers differ significantly, the tracking code may be firing twice (SGEN + GTM both injecting the same GA4 tag). Check Tools → Google Integrations and confirm GTM is not also configured to fire a GA4 tag for the same property.

• Save the off-platform backup somewhere you will find it.

The .sgen file is the full site restore. A backup on the platform and a backup in Google Drive, Dropbox, or a shared team folder is the minimum two-copy posture.

What the first week proves

The first week of live traffic surfaces things no pre-launch checklist can catch: real form submissions going to the wrong inbox, an Analytics property ID transposed by one digit, an SMTP credential that worked in testing but failed under real load. The six checks in this guide are the net that catches the common misses before they become client problems.

By the end of the first week, the site should have a confirmed analytics connection, a confirmed indexing state, tested form delivery, a clean SSL certificate, a backup on schedule, and a quiet Activity Log. That is the operational baseline from which stable site management starts.

Related reading

• SGEN Pre-launch Checklist — the 23-step sequence that runs before launch.

This guide picks up where that checklist ends.

• Backup and Restore — full backup schedule options, retention settings, and the restore procedure.
• Activity Log (in your SGEN admin) — filtering, exporting, and interpreting persistent log patterns.
• Decommission a Site — the orderly retirement playbook for when a site reaches end of life.