Find and undo a broken site edit using version snapshots
Traces a recent breakage on a hosted site to the snapshot and file that caused it, compares the file before and after, and restores only what is needed after your approval.
When to use it
When something on your hosted site broke after a recent edit and you need to find what changed and undo it safely.
What you get
The culprit file identified from snapshots with a before/after diff, the narrowest restore applied after your approval and confirmed live, plus a 4-line incident note for management.
Does it change anything in my account?
Only with your approval. The assistant first shows a preview of every change and waits for your go-ahead.
Fill in before sending
[affected page URL][approximate time of the edit]
Something on my hosted site broke after a recent edit: [describe the symptom, e.g. form missing, layout broken on mobile]. Find the cause and undo it with the smallest possible rollback.
0. List my servers and sites first. Version snapshots exist only on Opus Growth hosting servers. If [affected page URL] belongs to a WordPress site connected through the plugin, stop and tell me, because this rollback method does not apply there. If the server hosts more than one site, use the site that serves [affected page URL].
1. Read [affected page URL] live: HTTP status, response headers and HTML (use the outline view if the page is large). Take desktop and mobile screenshots.
2. List the automatic snapshots, paging back until you cover the last 14 days. Pick the snapshots around [approximate time of the edit]. Snapshots carry a time and a label, not the name of the person who made the edit, so rely on time and label only and do not guess who changed what.
3. For each suspected file, show the diff between the snapshot from just before the edit and the current file. Read the current file if you need more context. Explain in plain language what changed and why it causes the symptom.
4. Recommend the narrowest fix: one file, one folder, or the whole site only if several files are involved. List any later changes since that snapshot that would also be lost. If the site has a .src/ source folder (a build project), warn me that a restore will be overwritten by the next rebuild unless the fix is also carried into the source.
Run the restore as a preview first and show it to me. Do not apply anything until I approve. After I approve, apply the restore, read the page live again, take new screenshots, and confirm that the symptom is gone and the status is 200.
Finish with a 4-line incident note for management: what broke, when (based on snapshot times), impact window, and what was restored.
Finds page-one pages that get impressions but few clicks, compares them to your site-wide CTR, and rewrites their meta title and description around the queries that actually bring them traffic.
When to use itWhen your pages rank on page one and get impressions but few clicks, so your titles and descriptions are probably not convincing.
Matches GA4 landing-page performance against your WordPress menus, flags valuable pages missing from the navbar, dead weight and broken links, and proposes a leaner main menu.
When to use itWhen your site menu feels cluttered or outdated and you suspect it does not point visitors to the pages that actually bring conversions.
A plugin-by-plugin action list that flags outdated, duplicate and conflicting plugins and double-firing tags.
When to use itWhen your WordPress site has too many plugins, updates piling up, or you fear duplicate tags are inflating the conversions your ads optimize toward.