![Hero Image](/_next/image/?url=https%3A%2F%2Fassets.tina.io%2Fac949295-6f4c-48ea-8f33-2f825ae90bf5%2FCover-blog-Dev-Thoughts-ep-11.webp&w=3840&q=75)
How to migrate a PodBean podcast website to a custom website with Nginx permanent redirects
by Lucian Corduneanu • 3 months ago • 13 min read
Podcasts have become a powerful tool for sharing information and engaging audiences. But as your podcast grows, so do your needs. You might start out using a platform like PodBean, which offers convenient features like episode uploading and distribution. However, as your podcast gains traction, you may find yourself wanting more control over the look and feel of your website. This article will guide you through the process of migrating your podcast website from PodBean to a custom website, ensuring a smooth transition for both you and your listeners.
This step-by-step approach will equip you with the knowledge to:
- Leverage a VPS (Virtual Private Server) for secure hosting
- Utilize Nginx, a powerful web server, for managing redirects
- Employ Certbot to obtain and manage SSL certificates for secure communication
- Configure DNS records to direct traffic to your new website
By following these steps, you'll successfully migrate your podcast website, giving you the freedom to customize your online presence and enhance the listener experience.
This article dives deeper into the technical aspects of the migration process, providing valuable insights for those comfortable with technical configurations. So, if you're ready to take your podcast website to the next level, buckle up and get ready to migrate:
Context
Our podcast uses PodBean as a CMS to upload new episodes and distribute them to all major podcast platforms. We started with their website solution, but since our needs got more complex, we decided to build our own custom website page, within our NextJS & Tina CMS setup, but still use the RSS feed from PodBean to get the content.
Previously we used a CNAME DNS record to have a subdomain pointing to their website. The old URLs looked like this:
https://podcast.sensidev.net/e/episode-1-romeo-calota/
And we wanted to move it and incorporate it within our website with new URLs like this:
https://sensidev.net/podcast/episode-1-romeo-calota/
Brainstorming
Since the number of podcast URLs was not too high, but also not too low: 45 to be precise. We considered manually adjusting the old social media posts, but that was going to solve the problem only partially. Also, maybe if somebody had bookmarked the URL page – they would end up in a broken page after the migration to the new website. So we took a straightforward approach to using Nginx with permanent redirects.
Solution
We already had an existing Ubuntu VPS (Virtual Private Server), with the latest Nginx installed, and Let’s Encrypt Certbot that manages our SSL certificates. There are plenty of resources about how to install that, but a quick suggestion:
- Get a VPS from your favourite provider.
- Ensure you implement some basic cybersecurity measures like: Disable root ssh access, allowing only RSA key ssh authentication, maybe changing the default 22 ssh port, adding a fail2ban system and a simple firewall like `ufw` to allow only the traffic you want.
- Install Nginx for your OS.
- Install Certbot for your OS.
The idea now is to create a safe environment for the new Nginx server to configure and test, and only after everything feels right, should we switch to the production subdomain which in our case is `podcast`.
Certbot DNS Challenge
Considering you already own the domain name, in our case sensidev.net, from a domain provider. To manage the DNS records we use AWS Route 53, but there are other good options like CloudFlare.
Now that we have the VPS IP available, add an A DNS record for a new safe subdomain nobody is using. E.g. `newpodcast.sensidev.net`. Of course, replace `sensidev.net` with your domain name :)
In order to create a new SSL certificate for your `newpodcast.sensidev.net`, first make sure to install a Certbot DNS plugin:
After you follow the guide and configure the right permissions given to your specific DNS provider, then you are ready to create the SSL certificate.
certbot certonly --dns-route53 -d newpodcast.sensix.net
Good, now that you have an SSL certificate for the safe subdomain, let’s also create an Nginx server to redirect to the base page of the new website page, which in our case is https://sensidev.net/podcast/
List CertBot certificates, to double check if it is really there.
certbot certificates
Nginx Server
Create a new Nginx server that uses the SSL certificate and simply redirect (301) to the new website. Of course, depending on your OS put this file in the right place. For Nginx installed on Ubuntu, add it to
`/etc/nginx/sites-available/podcast.sensidev.net` and then make a symlink to sites-enabled.
server {
listen 80;
listen [: :]: 80;
listen 443 ssl;
server_name newpodcast.sensidev.net;
client_max_body_size 2M;
if ($scheme = http) {
return 301 https: //$server_name$request_uri;
}
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_certificate /etc/letsencrypt/live/newpodcast.sensidev.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/newpodcast.sensidev.net/privkey.pem;
rewrite ^/$ https: //sensidev.net/podcast/ permanent;
}
Link it, so that it makes it available in the site-enabled folder.
ln -s /etc/nginx/sites-available/podcast.sensidev.net /etc/nginx/sites-enabled/podcast.sensidev.net
Check if the nginx config is right and if so, restart the nginx service.
nginx -t
systemctl restart nginx
Now from your machine, check if the redirect is well configured.
curl -I https://newpodcast.sensidev.net/
But this is not enough, because only the root (or base URL) is redirected. What about all the episodes? At first we thought about using a regular expression to match all the old URLs and construct the new URLs, something like this:
rewrite ^/e/(.*)$ https://newpodcast.com/podcast/$1 permanent;
But we had an issue with this. It wasn’t that smooth because we had some exceptions in the format, so you guessed it, we ended up with a temp spreadsheet and used simple concatenate formulas to come up with the rewrite Nginx directives and that worked fine, since we wanted to cover only a fixed amount of 45 old URLs. I know, it is quite an archaic method, but it was simple and enough for our use case.
After copying and pasting all the `rewrite` directives, save the nginx config file, check the nginx config and restart the nginx server we ended up with a simple system that permanently redirects the URLs from the safe environment (the one using the `newpodcast` subdomain), to the new website.
Check some of the links to see if the SSL and permanent redirect is in place.
curl -Iv https://newpodcast.sensidev.net/
curl -Iv https://newpodcast.sensidev.net/e/episodul-44-ovidiu-bite/
Switch to the prod subdomain
After you are ready and you double checked everything is prepared for making the switch for real, you have to deal with:
1. Create an SSL certificate for the real `podcast` subdomain.
certbot certonly--dns - route53 - d podcast.sensix.net
2. Edit the Nginx server configuration so you find and replace all `newpodcast` with `podcast`, make sure you cover the server name, ssl certificate and rewrite directives.
3. Replace the `newpodcast` with the real `podcast` subdomain in your DNS provider dashboard. Also remove the old CNAME DNS record for the `podcast` subdomain.
4. Check the nginx config, restart nginx service
nginx - t
systemctl restart nginx
5. Check the new subdomain URLs point to the right new website URLs.
curl - Iv https://podcast.sensidev.net/
curl - Iv https://podcast.sensidev.net/e/episodul-44-ovidiu-bite/
6. Clean up the old certificate for the safe (temp) environment.
certbot delete --cert-name newpodcast.sensidev.net
One more thing
Likely when moving to a custom podcast site you will not want the default PodBean website to coexist with it, because of SEO duplicate content. Meanwhile, you can’t completely get rid of the default website, what you can do is to exclude it from being indexed by search engines.
This is as simple as using the “SEO Meta Tags” PodBean plugin and adding here a meta directive to prevent indexing.
<meta name="robots" content="noindex, nofollow" />
Conclusion
Just for the sake of old URLs backward compatibility with the new podcast website, we decided to bear the cost of a VPS. We needed to make sure an Nginx, Certbot and DNS plugin was in place on that VPS and also make sure we followed basic cybersecurity guidelines to secure the VPS. We updated the DNS A and CNAME records to end up with a new use for our subdomain, previously used to point to PodBean.
I am sure there are also other methods to achieve the same. I’d be happy to see how you’d approach this in the comments section below.
Dev Thoughts
![The Product Owner’s View Building a Streamlined Transport Management System](/_next/image/?url=https%3A%2F%2Fassets.tina.io%2Fac949295-6f4c-48ea-8f33-2f825ae90bf5%2FCover-blog-Dev-Thoughts-ep-10.webp&w=1920&q=75)
The Product Owner’s View: Building a Streamlined Transport Management System
by Alexandra Voinea • 3 months ago• 5 min read
![Mobile App Development in Action](/_next/image/?url=https%3A%2F%2Fassets.tina.io%2Fac949295-6f4c-48ea-8f33-2f825ae90bf5%2Fimages%2FCover-blog-Dev-Thoughts-ep-9.webp&w=1920&q=75)
Improve Your Dev Journey: Essential Skills Beyond Just Coding
by Dragos Ispas • 3 months ago• 5 min read
![Building a Multi-Platform Driver Onboarding Application with React Native](/_next/image/?url=https%3A%2F%2Fassets.tina.io%2Fac949295-6f4c-48ea-8f33-2f825ae90bf5%2Fimages%2FCover-blog-Dev-Thoughts-ep-8.webp&w=1920&q=75)
Building a Multi-Platform Driver Onboarding Application with React Native
by Gabriel Macovei • 4 months ago• 5 min read