Philosophy and scope
The rollback manifest: file list, backup, one-step reversal and the drill.
SafeFix's philosophy is safe improvement, not rebuilding. The existing site is an asset: content, structure, link history. SafeFix preserves that asset and applies only low-risk, reversible changes on a working copy. 'Low risk' is measurable here: a change touches either the meta layer (title/description/OG/Twitter/JSON-LD), delivery hygiene (sitemap/robots/llms.txt/favicon), or behaviour-neutral security readiness (an .htaccess header recipe).
Every SafeFix run produces three proofs: the changed-file list, the rollback manifest and the before/after internal readiness score. The rollback manifest contains the backup directory, changed and created files — full one-step reversal is possible. This is the engineering answer to 'what if the engine breaks the site'.
Scope examples: missing meta/canonicals completed; OG/Twitter fields generated; baseline JSON-LD added; sitemap/robots/llms.txt created or fixed; security headers prepared via the .htaccess recipe; defer applied to render-blocking external scripts; dimensionless images flagged. The security boundary holds: SafeFix never adds CSP-breaking tricks such as inline-onload, and never produces a duplicate policy when the site has its own CSP.
When SafeFix is not done is also defined: bulk edits in third-party theme files of unclear origin, text interventions that change meaning, risky rewrites dependent on server behaviour, and brand/language changes requiring client approval. These items go to human approval or external action.
The evidence package
The SafeFix evidence package: six delivery items.
Every WebTrustEngine run leaves an evidence package; the report is not a PDF page but an auditable file set. Its core: before score, after score, changed files, rollback manifest, external actions, the runtime-checks list, manual-verification items, the QA report, the manifest and checksums.
This structure delivers two things at once: the story for the executive (what changed, what was gained) and verifiability for the auditor (which file, which hash, which boundary). Checksums are computed from real files after packaging; the manifest lists every file's size and type. The evidence package makes 'trust us' unnecessary — the files speak.
- before/after score
- changed files
- rollback manifest
- external actions
- runtime checks
- manual verification
- QA report
- manifest + checksum
What the engine does: Produces an auditable file set per run.
What it doesn't: Does not produce a one-page 'trust us' report.
What the output is: A 10-part evidence set (score→checksums).
For decision-makers: Auditability equals credibility.
For technical teams: Hash/manifest discipline locks delivery quality.
Evidence file dictionary
The files you will meet in the delivery ZIP, each with its one-line duty
- RUN_SUMMARY.json — The run's summary record: input, mode, page count, before/after score.
- SKOR_RAPORU_*.md — The 10-domain table + fix types + external-work list.
- FIX_MANIFEST.json — Type-and-count breakdown of applied changes.
- ROLLBACK_MANIFEST.json — backup_dir + changed + created file lists.
- DEGISEN_DOSYALAR_*.txt — The human-readable changed-file list.
- EXTERNAL_ACTION_RECIPES.md — Panel/DNS/account recipes under 24 headings.
- RUNTIME_BRIDGE_KONTROLLERI.md — The tool/metric/how map of the 21 live checks.
- MANUAL_VERIFICATION_RULES.md — Items awaiting human approval, with rationale.
- GODADDY_YUKLEME_TALIMATI.md — Upload + cache + verification steps.
- MANIFEST_*.csv — The file/size/type inventory of the package.
- CHECKSUMS_*.sha256 — Integrity digest of every file; produced after packaging.
- QA/PATCH/COUNT reports — The release's quality, change and count evidence.
PROCESS
The safe loop in six steps
Scope approval
What will be touched is fixed by written approval.
evidenceWorking copy
The isolated copy changes, never the live files.
evidenceLow-risk fixes
Meta layer, delivery hygiene, header recipe.
evidencereversibleManifest + diff
Every change is written to two manifests.
evidencereversibleBefore/after score
A comparable pair of scores across the same ten domains.
evidenceRollback rehearsal
One file is restored from backup; the return is proven.
evidence
Deliverables
SafeFix Deliverables
Not a score; an auditable file set
Fixed site ZIP
publish-ready working copy
Changed files
full list · file level
Rollback manifest
one-step reversal
Before/after score
internal readiness diff
External recipes
platform work separated
Live verification list
post-upload steps
No guarantees — readiness, evidence and verification. Number contract: 2,033 reference catalog · 319 working checks.
SCOPE CLASSES What it touches — and refuses to
Touches: the meta layer
Title/description tags, Open Graph, canonical and hreflang links, JSON-LD blocks.
Touches: delivery hygiene
Generation and consistency of sitemap.xml, robots.txt, llms.txt, security.txt.
Touches: the header recipe
A ready, conflict-free block of security headers to apply at the server.
Never: content judgement
Rewriting copy, swapping imagery, brand wording — these go to the approval queue.
Never: risky rewrites
Theme/template cores, behaviour-changing scripts; outside the SafeFix definition by design.
Never: the live system
Changes stay in a working copy; deploying and verifying is a separate, deliberate step.
BEFORE/AFTER How to read the before/after pair
Both scores are produced by the same 319 checks, on the same day, over the same file root; the only variable is the applied fixes. The delta is therefore a measurement difference, not an improvement claim. Domains that do not move carry information too: their work lives on external platforms or in live verification — and the report says so explicitly.
The guarantee against inflation is structural: the engine grades its own fixes under the same rules it grades everything else, and a 'passes in production' note is never produced under any condition. The pair collapses into one slide for the board: what changed, in which file, with what score effect — three columns, zero adjectives.
NOT AUTOMATED What it deliberately leaves to humans
Five jobs stay in human hands by design: content and tone decisions; brand imagery; the meaning of legal text; information-architecture changes; and deployment itself. This list is not a shortfall — it is the definition. The word 'safe' comes from reversibility plus these boundaries.
The approval model is simple: scope is approved in writing, fixes are applied in a working copy, the package ships with its manifests, and the go-live decision remains yours. At no stage does the engine touch production 'on your behalf'.
FROM THE FIELD
What SafeFix looks like in practice
SafeFix exists for one stubborn reality: most websites do not need a rebuild, they need a set of small, provable repairs that nobody dares to make because nobody can promise a way back. The mode answers that fear structurally. Nothing is edited in place; a working copy is taken, and only changes classified as low-risk are applied — the meta layer, delivery hygiene, header recipes, link and asset corrections that alter no visible design and no URL.
Every touched file is recorded twice: once in a fix manifest that stores the before/after hash of each file, and once in a rollback manifest that can restore the previous state in a single step. A diff report shows each change in context, so a reviewer approves lines, not adjectives. The before/after score pair then measures the improvement on the same ten-domain ruler that produced the baseline — the ruler never moves to flatter the number.
Just as important is what SafeFix refuses to do automatically: it does not rewrite content, redesign layouts, restructure URLs, touch server configuration or push anything live. Those either belong to Build, to an external action recipe on your hosting platform, or to a human decision. The mode's promise is deliberately narrow, which is exactly why it can be kept.
CASE STUDY
The life of one fix: a missing canonical
Concretely: a Review classifies twenty-two pages of a corporate site as lacking a canonical tag entirely, with three more carrying a self-contradicting address. The finding qualifies for SafeFix because the risk is low — one line in the head, no visible change anywhere.
In the working copy the engine derives each page's absolute address and inserts the tag. Three artifacts are born in the same moment: a changed-files list (25 rows), the fix manifest with per-file hashes, and the rollback manifest. Before delivery a rollback rehearsal runs: one file is genuinely restored from backup and its hash compared to the original — turning "reversible" from a sentence into evidence. The publish decision stays with you; the engine produces files, your approval carries them live.
Quick answers
If the site breaks?
The rollback manifest reverts in one step.
Live sign-off?
No; upload + Deploy-Verify required.
What does it fix?
Meta layer, delivery hygiene, header readiness.
Does it touch content?
No meaning-changing edits.
Who approves?
Publishing is always a human decision.
Next step
Low-risk fixes on a working copy: changed-file list, rollback manifest, before/after score.