Build a URL acceptance ledger before moving WordPress

A migration trial needs more than an imported-record count. A reader may depend on an old article address, an image URL, a language link or a form supplied by a WordPress plugin. Build a small URL and behaviour ledger before moving the domain. This walkthrough concerns the acceptance work around an import; it does not claim that every plugin or custom process can be converted to GoRun.

1. Select a representative pilot

Choose a long article, a page, a media-heavy entry and the languages the site actually publishes. Include one important form or custom content type if it is within the agreed scope. Write down why each example matters. Do not choose only the cleanest pages: the pilot should expose the cases that could stop a real visitor from finishing a task.

2. Build the URL ledger

Create columns for the original URL, content type, language, proposed destination, required behaviour and review owner. Record the complete relevant path, including meaningful query parameters when the old workflow depends on them. Mark whether the destination should be a direct page, a deliberate redirect or an intentionally retired item. An empty destination is a decision still to make, not permission to send everything to the homepage.

3. Separate content from plugin behaviour

For each selected page, list what comes from the content record and what comes from a plugin or custom code. A contact form, restricted download or payment step is behaviour, not simply a paragraph to import. Verify the supported importer scope for the installed release and identify any replacement work explicitly. Keep the original site available while testing a separate destination.

4. Inspect the destination as a reader

Compare the expected records by type, language and publication status. Open the actual destination URLs. Inspect headings, tables, images, captions and internal links. A media URL still pointing to WordPress is not proof that its file has been copied. A successful import job is not proof that the destination behaves correctly, and a translated menu label is not proof of a translated article.

5. Test redirects with their final destination

Follow each pilot redirect through to its result. Check that the reader reaches the intended page and language, without a loop or an unnecessary chain. Record the observed result beside the planned destination. Leave unresolved mappings visible and assign an owner. Test forms only under an agreed procedure that avoids unintended real enquiries or transactions.

Before expanding the import

• The pilot content and media have been inspected.
• Plugin-dependent behaviour has an agreed treatment.
• The URL ledger has reviewed destinations.
• Arabic and English paths have been checked separately.
• The final editing window and recovery decision are understood.

Resolve the pilot gaps before enlarging the batch or changing DNS. Do not promise preserved rankings or traffic from an import count. The migration guide explains overall scope; use server preparation and recovery planning for the destination and cutover responsibilities.