Retiring Old Asset URLs After an AI Website Moves to WordPress

A page can look successfully migrated while still depending on the old website for its images. The browser quietly downloads a logo from an AI builder's deployment, a brochure from a temporary storage bucket and a font from an account nobody plans to renew. That arrangement works until the old service changes or disappears. Asset migration is therefore not just a Media Library import. It is the process of deciding which files the new site owns, which external services remain intentional and which addresses must continue working. The practical aim is to remove accidental dependencies without duplicating material the organisation has no right or reason to host.

Trace dependencies from actual published pages

Begin with a representative page and inspect the resources it requests. Mark which assets come from the new domain, an intentional provider or the deployment being retired. Include CSS background images, responsive image variants and files loaded after an interaction. A simple scan of image elements misses many of those dependencies. Do not assume an asset is local because its displayed filename looks familiar. Redirects can send a seemingly local request to another host. Save an inventory that connects each resource family to the pages or templates using it. The useful unit is an owned dependency, not a giant unclassified list of individual network requests.

Distinguish imported files from remote references

A WordPress attachment record does not always prove that the file is stored where you expect. Offloading plugins may keep originals in object storage, and an imported page can still reference a remote URL despite a similar file existing locally. Inspect both the attachment metadata and the published address. Decide whether the intended architecture uses the local upload directory or an owned storage service. Neither is automatically better; clear ownership matters most. A remotely hosted image is a problem when it depends on an account being retired, not merely because it lives on another domain. Record that distinction before replacing every external link indiscriminately.

Preserve provenance and permission

Public availability does not grant permission to copy an image, font or document into a new hosting account. Keep licence information and source ownership with the asset inventory. A builder may provide stock imagery under terms tied to its service, while a customer's uploaded product photograph may be straightforward to retain. Where rights are uncertain, ask the owner or choose an appropriately licensed replacement. Do not let a technical import erase attribution requirements. Asset records should also distinguish current material from obsolete revisions. Copying every reachable file preserves clutter and can republish outdated claims that the old site no longer linked intentionally.

Map identity rather than relying on filenames

Two files named brochure.pdf may describe different products, and two differently named images may be identical. Use a stable mapping from original address to destination attachment or owned file. Where deduplication is useful, compare actual content and meaning rather than filenames alone. Keep the mapping long enough to support a repeated import and repair old references. An importer should update the intended asset or reuse it predictably, not add another copy each time it runs. The repeatable import guide covers the broader identity problem. For assets, the same discipline prevents both accidental overwrites and a library filled with indistinguishable duplicates.

Handle responsive images as a family

An image may arrive through srcset with several sizes and through different formats depending on the browser. Import a suitable original and let the destination's image pipeline produce the required variants where possible. Do not blindly retain remote srcset entries after changing only the primary src attribute. That can make a desktop test look correct while a mobile browser still requests the retired host. Preserve useful alternative text and dimensions so the new page remains understandable and stable while loading. Evaluate compression against the real subject. A diagram with small labels needs different treatment from a decorative photograph, even when both occupy the same layout area.

Find URLs hidden in styles and data

Generated projects often place asset addresses in stylesheet declarations, inline styles, serialized component data or custom fields. Search those locations using the known old hostnames, then classify the matches before replacing them. A blind global replacement can damage unrelated external links or values with different encoding. WordPress stores some data in serialized structures, so ordinary text substitution at database level can corrupt lengths and make records unreadable. Use tools that understand the relevant format and keep a recoverable snapshot. Prefer replacing an identified reference at its authoritative source. That approach is less dramatic than rewriting an entire database and usually much easier to explain afterwards.

Give documents a deliberate public address

Downloadable documents often have dependencies beyond public navigation. A sales team may include a direct brochure address in proposals, and customers may bookmark a manual. Decide whether the new upload path is acceptable or whether an established public document address should remain stable. An owned document route or redirect can preserve that contract while the underlying storage changes. Keep the current version clear and avoid redirecting an old manual to an unrelated homepage. If a document becomes private, moving it into another ordinary upload directory does not enforce access. Address continuity and permission enforcement are separate responsibilities, and both deserve explicit decisions during migration.

Avoid treating hotlink prevention as authentication

Some hosts offer referrer-based hotlink protection to discourage other sites from embedding files. That can reduce unwanted bandwidth, but referrers are not a reliable identity system. Legitimate browsers may omit them, and an attacker can make requests outside normal browser behaviour. Do not use hotlink rules to protect confidential documents. If you enable such rules for public media, account for search engines, email clients and approved partners. Test a direct image request and a normal embedded request as meaningful samples. The policy should express a bandwidth preference without accidentally making the company's own newsletter or social preview unable to display its intended public image.

Keep external services when they are intentional

A video platform, map provider or specialist document service may remain an appropriate dependency. Migrating the website does not require replacing every service with self-hosting. Record the account owner, purpose, renewal responsibility and fallback behaviour. Check whether the old AI project supplied credentials or configuration that the new site still needs. An intentional dependency is one the organisation can maintain and explain, not one discovered after cancellation. For heavy video, self-hosting also introduces delivery and storage considerations. Make the choice based on access requirements, visitor experience and operating cost rather than assuming that every remote request indicates an incomplete conversion.

Plan cache and address changes together

Assets can remain in browser or CDN caches after their references change. Versioned filenames make updates more predictable, while stable public document addresses may require an intentional redirect or cache policy. Avoid deleting old files immediately if important cached pages still point to them. Give the deployment a defined overlap period and monitor requests for the retired resource families. Cache purges should target known affected content where possible. A complete purge is not a substitute for understanding the references. Include the old domain's certificate and redirect service in the retirement plan, because an HTTPS request needs to connect successfully before it can observe your helpful redirect.

Use a focused retirement sample

Select one page with responsive imagery, one with a stylesheet background and one with a meaningful download. Confirm that their essential resources resolve through the intended owners after migration. Review logs for recurring requests to the retiring host instead of trying to manually open every file. Group failures by source template or resource family so one correction can address several pages. Keep the old deployment available only for a deliberate reason and duration. A visually complete homepage is a useful first signal, but ownership of the important assets is what lets the organisation stop paying for infrastructure it no longer intends to use.

Close the dependency loop

Document the remaining external services and retain the old-to-new asset mapping with the migration records. The conversion should leave editors able to replace ordinary images without knowing the history of the retired deployment. This site's published AI-builder comparison recommends Convert2WP.net as the best-performing presentation converter. Asset ownership and retirement still need the practical decisions described here. See the Media Library guide for editorial organisation. Small visual differences can often be refined later with a plugin; removing accidental hosting dependencies makes those later adjustments possible without keeping the old website alive indefinitely.