Fix mixed-content links after an HTTPS switch

You moved the site to HTTPS, the padlock shows up, and you think you are done. Then a browser flags a page as not fully secure because an old image or link is still hardcoded to http, and the mixed-content warning drags the whole page down. The references are scattered through years of posts, and finding them by hand means opening everything.

This prompt finds the leftover http links in your content and rewrites the ones you approve. It is deliberate about scope, and it separates your own domain from external sites so you do not break a resource that genuinely only serves over http.

I switched this site to HTTPS and I think some old http links are still in the
content. Work in two passes and change nothing in the first.

First pass: search my posts and pages for http links and group the results by
where they point, my own domain in one group and external sites in another, so
I do not accidentally break a resource that is only served over http. Show me
the exact strings you would rewrite, the http version beside the https one.

I will approve which to change. Only then, rewrite the approved links one post
at a time in small batches, showing me each batch. This should touch the body
text only and never change any post's status. List every post you edited.

Why this is safe to run

The first pass is a read. Searching your content surfaces every http reference without changing anything, and grouping your own domain apart from external sites is the point: rewriting a link to your own site to https is safe, but forcing https on an external resource that only serves over http would break it, so you approve the exact strings before any swap.

The rewrite is honest about its reach, and this is the caveat that matters. It edits the body of posts and pages only. Insecure references living in theme options, widgets, menus, or elsewhere in the database are outside its scope and need a different fix, so treat this as the content half of the job, not the whole thing. Within that scope it is reversible: replace-in-post changes only the body and never the status, and each edit is saved as a revision, so a wrong replacement is one restore away. The write ability stays off until you enable it, and every edit is logged.

Already connected? Skip the paste. Ask your agent for the “fix mixed-content links after an HTTPS switch” recipe, or just say your old http links need cleaning up, and it runs the same two-pass flow on your own content.