How to Move Your Radio Station Website Without Changing Your Stream Host

Your website and your stream are separate things. The stream comes from your stream host or server (Icecast, SHOUTcast, AzuraCast, Radio.co, RadioKing, RadioHost Studio or anyone else); the website is the page with the player, schedule and everything around it. You can replace the website without touching the stream, and listeners using apps, smart speakers or directories won't notice a thing.

What can go wrong is everything around the domain: old links that stop working, email that stops arriving because a DNS record was deleted, or a podcast feed that vanishes. This guide is the order of work that avoids those. It is written for moving to RadioSiteMaker, but the steps apply to any platform.

Be clear about one thing up front: there is no automatic site import. Pages, show descriptions, DJ bios and blog posts are copied across by hand. Podcast episodes are the exception, because RadioSiteMaker can import them from your podcast's RSS feed. Budget time for the copying, and expect a short period during the switch when some visitors still reach the old site while DNS updates.

Step 1: Inventory the old site

Before you build anything, write down what you have. You need two lists.

Content. Every page type and what's on it: home, about, schedule, each show, each DJ or presenter, events, blog posts, podcasts, donation and contact pages, any embedded widgets (chat, request forms, social feeds). Note which items are still current; a migration is a good moment to drop what's out of date.

URLs that matter. Not every old URL needs saving, but the ones people use do. Find them in:

• Google Search Console (Performance and Pages reports): pages that get search clicks.
• Your analytics: the most visited pages.
• Places you link from: social profiles, directory listings (TuneIn, radio.net and so on), printed material, email signatures, podcast show notes.

Also note your stream URL and, if you publish a podcast, its feed URL and where it is hosted. Neither should change in this migration.

Step 2: Build and stage the new site on your free subdomain

Sign up and build the new site on the free subdomain you get at sign-up (yourstation.radiositemaker.com). Your current site stays live on your domain the whole time, so there's no rush and no downtime while you work.

1. Paste the same stream URL you use today. The player connects to your existing stream host; nothing changes at the host.
2. Recreate your shows and the weekly schedule, then your DJ and presenter profiles.
3. Copy pages, bios and blog posts across by hand. Where you can, give items the same slug (the last part of the URL) they had before; each show, DJ, post and event has an editable slug.
4. For podcasts, create the series and paste your existing feed URL to import the episodes. The episodes keep pointing at the audio files on your podcast host, so keep that host.
5. Add events, donation links (PayPal, Stripe, Ko-fi, Buy Me a Coffee, Patreon or GoFundMe) and your contact details.

Here is what the schedule looks like once your shows are in, on a demo station:

RadioSiteMaker's trial is 7 days with no card required, so plan your content copying around it or subscribe ($99/year + tax) once you know it fits.

Step 3: Record your DNS and email settings before touching DNS

This is the step that prevents the worst outcome. Your domain's DNS zone holds more than your website: it also tells the world where your email goes (MX records) and holds verification and anti-spam records (TXT records for SPF, DKIM, Google or Microsoft verification).

Before you change anything:

1. Log in where your domain's DNS is managed (your registrar, Cloudflare, or your old web host).
2. Export the zone file if offered, or take screenshots of every record.
3. Note specifically: the current www record (type and value), any A or AAAA records for the bare domain, all MX records, and all TXT records.
4. Lower the TTL on the www record to something short, such as 300 seconds, a day before you switch, so a change (or a rollback) takes effect faster.

For the switch you will change only the www record. Leave MX and TXT records alone. If your old web host also manages your DNS or your email, check before cancelling it; cancelling the hosting can take the DNS and mailboxes with it.

Step 4: Map your redirects

A redirect sends someone who visits an old address to the new one. Here is the honest version of how redirects work in this move.

RadioSiteMaker serves its own page paths on your domain: /schedule, /djs/<name>, /shows/<name>, /podcasts/<name>, /blog/<post>, /events/<event>, /about, /contact and so on. It does not have a redirect manager for importing a list of old URLs. Once www points to RadioSiteMaker, the old host no longer sees those requests, so it can't redirect them either. That leaves three tools:

• Keep the same paths where you can. If your old site already used paths like /schedule or /about, they keep working. Where only the prefix differs, reusing the old slug at least keeps the name recognisable.
• Redirect at the old host or registrar for addresses that aren't www. If your old site lived on the bare domain (yourstation.com), on another subdomain or on a different domain entirely, that address can stay with the old host or registrar and redirect page by page to the new URLs. Many registrars offer forwarding for a domain; path-by-path rules depend on your registrar or host.
• Update the links you control. Social profiles, directory listings, newsletter templates and podcast show notes can all be pointed at the new URLs directly.

Make a simple table of old URL, new URL and how it will be handled (same path, redirect elsewhere, or updated link). For the pages that got search traffic, make sure the content exists on the new site, so search engines can find it again through your sitemap even where the old address can't redirect.

Don't change your podcast feed URL as part of this. Podcast apps follow the feed they subscribed to; if that URL stops working without a redirect from the old host, subscribers silently stop getting episodes. Keep the feed on your podcast host.

Step 5: Verify everything on the subdomain

Before switching the domain, test the new site on its subdomain as a listener would, on a computer and a phone:

• Player: press play, then click through several pages. The audio should keep going. Check the song title and artist appear. If not, see radio player troubleshooting.
• Schedule: check show times in your station's time zone, and that the on-air show is right.
• Podcasts: episodes imported, playable, in the right order.
• Forms: send a test through the contact form and check it arrives.
• Donations and other outbound links: click each one.
• SSL: the address bar shows a padlock on every page.
• Content: spot-check against your Step 1 inventory.

Step 6: Switch the custom domain

When you're happy, point the domain at the new site:

1. In your RadioSiteMaker dashboard, go to Settings → Custom Domain and enter your domain with www (for example www.yourstation.com). RadioSiteMaker supports www domains. The dashboard shows the exact record to add.
2. At your DNS provider, replace the existing www record with a CNAME record: name www, value sites.radiositemaker.com. A CNAME can't share its name with other records, so remove the old A or CNAME for www rather than adding alongside it. If your DNS is on Cloudflare, set the record to DNS only (grey cloud), not proxied.
3. Back in Settings, use Check status. Once DNS is verified, the SSL certificate is set up automatically; that usually takes a few minutes after DNS has updated, though DNS itself can take longer to reach everyone.
4. For the bare domain (yourstation.com), set up forwarding to https://www.yourstation.com at your registrar so people who type it without www still arrive.

During the change, some visitors may still reach the old site for a while, depending on DNS caching. That's normal, and another reason to keep the old site running for now.

Step 7: Watch Search Console

Search engines will recrawl your site over the following days and weeks. Help them and keep an eye on problems:

1. In Google Search Console, add (or reuse) a Domain property for your domain; it is verified with a DNS TXT record, so it covers www whatever platform serves it.
2. Submit the new sitemap: https://www.yourstation.com/sitemap.xml. RadioSiteMaker generates and updates it automatically.
3. Check the Pages report for "Not found (404)" entries and compare them with your Step 4 table. Fix what you can: add missing content, update links, or set redirects where you have a host that can serve them.
4. Use URL Inspection on your most important pages to confirm Google sees the new versions.

Some movement in search results after a platform change is normal. Watch the trend over a few weeks rather than reacting to a single day. The SEO guide covers what to work on next.

Step 8: Keep a rollback window

Don't cancel the old hosting on switch day. Keep it running for a few weeks, so that:

• if something important is broken, you can put the old www record back (you noted it in Step 3) and be back on the old site as soon as DNS updates;
• you can still copy anything you forgot;
• any redirects you set up on the old host or registrar keep working.

Once the new site has run cleanly for a while and Search Console looks settled, cancel the old hosting, but keep the domain registration, your DNS records and your email exactly as they are.

Migration checklist

Copy this into a document or print it:

BEFORE
[ ] List all pages and content on the old site
[ ] Export top URLs from Search Console and analytics
[ ] Note stream URL and podcast feed URL (neither changes)
[ ] Build the new site on yourstation.radiositemaker.com
[ ] Copy shows, schedule, DJs, pages and posts by hand
[ ] Import podcast episodes from the RSS feed
[ ] Export or screenshot every DNS record (www, apex, MX, TXT)
[ ] Lower the TTL on the www record a day ahead
[ ] Write the old URL -> new URL table and how each is handled

TEST ON THE SUBDOMAIN
[ ] Player plays, keeps playing across pages, shows song titles
[ ] Schedule times and time zone correct
[ ] Podcast episodes play
[ ] Contact form test message received
[ ] Donation and outbound links work
[ ] Padlock (SSL) on every page, desktop and phone

SWITCH
[ ] Enter www.yourstation.com in Settings -> Custom Domain
[ ] Replace the www record with CNAME -> sites.radiositemaker.com
[ ] Cloudflare users: DNS only (grey cloud)
[ ] Check status until verified and SSL is active
[ ] Forward the bare domain to https://www.yourstation.com
[ ] MX and TXT records untouched; send a test email

AFTER
[ ] Submit https://www.yourstation.com/sitemap.xml in Search Console
[ ] Check the Pages report for 404s weekly
[ ] Update social profiles and directory listings
[ ] Keep old hosting for a few weeks as a rollback

Frequently Asked Questions

Will my stream go off air during the move?

No. The stream is served by your stream host, not your website. Nothing in this process changes the stream, so apps, smart speakers, directories and anyone listening directly keep working. The new site's player connects to the same stream URL.

Can RadioSiteMaker import my old website automatically?

No. There is no site import tool, so pages, shows, DJ profiles and posts are copied by hand. Podcast episodes are the exception: paste your podcast's RSS feed URL and the episodes are imported. Moving from WordPress specifically? See migrating a WordPress radio website.

Will my email stop working when I change the domain's DNS?

Not if you only change the www record. Email is controlled by the MX records (and related TXT records), which you leave exactly as they are. The risk comes from deleting records, moving the DNS to a new provider without copying them, or cancelling an old host that also runs your DNS or mailboxes.

Can I use my domain without www?

RadioSiteMaker serves custom domains on www. Set up forwarding from the bare domain to the www address at your registrar, so visitors who type it without www still reach the site.

How long does the switch take?

The DNS change and certificate usually complete within minutes to hours, depending on your DNS provider and the TTL you set. The work before it, copying content and testing, takes most of the time. Search engines take days to weeks to recrawl and update their results.