A WordPress Developer's 7-Day Log: Rebuilding a Fertility Clinic Site with Fertilys
I have spent more than ten years building websites, launching web-based games, and helping businesses clean up their search engine optimization (SEO). Over the years, I have seen almost every type of client request. But medical sites—especially those dealing with reproductive health, in vitro fertilization (IVF), and prenatal care—are always a unique challenge.
These sites fall under Google's "Your Money or Your Life" (YMYL) category. The search engines look at them with a magnifying glass. The design cannot just look pretty. It must feel safe, loads fast, and show true credibility. If a user feels anxious or gets confused by a messy layout, they will leave immediately.
Recently, a local fertility clinic group reached out to me. Their old website was a complete disaster. It was built back in 2017 using a generic page builder that had not been updated in years. The mobile version looked broken, the contact form frequently failed to send patient inquiries, and the home page took almost nine seconds to load on a standard mobile connection.
They needed a complete rebuild. We decided to use a dedicated WordPress theme that fits this specific medical field. After searching through several options, we picked the Fertilys – IVF, Pregnancy & Maternity Healthcare WordPress theme.
Below is my honest, day-by-day developer diary of how I set up, modified, optimized, and launched this website over a seven-day period.
Day 1: Preparing the Server and Clean Installation
Before you even touch a WordPress theme, you need to make sure your hosting environment is ready. Many developers make the mistake of installing heavy modern themes on cheap, shared hosting accounts that use old versions of PHP. When they do this, they wonder why the layout editor crashes or why the site loads slowly.
For this project, I set up a staging environment on a cloud virtual private server (VPS) running LiteSpeed Enterprise with 2 CPU cores and 4GB of RAM. This is more than enough for a local clinic, and it provides a very fast baseline.
I logged in via SSH and checked the environment. First, I updated the PHP version to 8.2. While some older themes struggle with modern PHP versions, any modern theme built for today's market should run on PHP 8.2 or 8.3 without showing a screen full of deprecation warnings.
Next, I opened my PHP configuration file (php.ini) to adjust the limits. Elementor and modern clinic layouts need a bit of breathing room to process dynamic queries. I updated the following lines:
max_execution_time = 300
memory_limit = 512M
post_max_size = 64M
upload_max_filesize = 64MAfter restarting the PHP service, I used WP-CLI to install a fresh copy of WordPress. I prefer using the command line because it keeps the installation clean and avoids any pre-installed junk plugins from web hosts.
# Download the latest WordPress core in English
wp core download --locale=en_US
# Create the database configuration file
wp config create --dbname=clinic_staging_db --dbuser=db_admin_user --dbpass=secure_password_here --dbcollate=utf8mb4_unicode_ci
# Install the WordPress core database tables
wp core install --url=https://staging.clinicgroupsite.com --title="Maternity & Fertility Care" --admin_user=dev_lead_maternity [email protected]Once the core files were ready, I cleaned up the default installation. I deleted the default themes (Twenty-Twenty-Two, Twenty-Twenty-Three, etc.) and removed the default plugins like Hello Dolly and Akismet, which we would not be using.
With a completely blank slate, I uploaded the main zip file of the theme and its child theme. I always activate the child theme immediately. Even if you do not plan on writing custom code on Day 1, you will inevitably need to write some on Day 3 or Day 4. Modifying the main theme files is a terrible habit because your custom work will get wiped out the moment the theme developer releases an update.
Day 2: Importing the Demo and First Assessment
On the second day, I focused on importing the demo data to see how the layout structured its pages. Many developers hate demo importers because they often import hundreds of low-quality images, broken links, and dozens of unnecessary menus. However, with highly specialized healthcare sites, importing the demo helps you see how the custom post types—such as "Doctors", "Services", and "Departments"—are linked together.
I clicked the one-click demo importer provided in the admin panel. The importer went to work pulling in the templates, the sample pages, and the default settings.
The import finished in about four minutes. I opened the front end of the site, and the structure of the fertility clinic looked clean. The theme uses soft pinks, gentle blues, and warm grays. This color palette is excellent for a pregnancy and IVF center because it creates a calm, comforting atmosphere.
However, looking at the backend, I noticed that my database had ballooned. The importer had created over forty dummy blog posts, fifteen duplicate page templates, and a massive library of heavy stock images.
I spent the next three hours cleaning this up. I deleted all the unnecessary dummy blog posts and went through the media library to delete duplicate graphics.
I also ran a quick initial speed test using Google PageSpeed Insights on the raw, unoptimized demo home page. The results were not great, but this is normal for a raw demo import: Mobile Score: 41/100 Desktop Score: 72/100 Main Issues: Large image sizes, uncompressed assets, and render-blocking scripts from multiple plugins.
This initial test gave me my roadmap for the rest of the week. I knew I had a lot of work to do to make this site load fast enough for mobile users who might be searching for clinic info on weak cellular networks.
Day 3: Facing Technical Friction and Writing a Code Solution
On Day 3, I ran into my first real technical problem. This is the moment in any project where a generic tutorial fails you, and you have to dig into the actual code of the site.
The client wanted to display a clean grid of their medical team. The theme uses a custom post type called doctors to display these staff members. Each doctor has a profile photo, a list of specialties, and a button to book an appointment.
When I uploaded high-resolution headshots for the first five doctors, I noticed two major issues:
- Server Bloat: The theme and WordPress combined were registering more than ten different image sizes. Every time I uploaded a single staff portrait, the server generated ten cropped copies of it. This was eating up disk space on the server and slowing down our automated backup processes.
- Query inefficiency: The theme’s custom Elementor widget for the doctor list did not allow us to exclude specific doctors who were temporarily on leave or retired, unless we created a completely separate taxonomy. The query was pulling every doctor post type without a simple way to filter them via custom fields.
To solve both of these problems, I decided to write some custom PHP code in the child theme’s functions.php file instead of installing heavy custom query plugins.
First, I wrote a function to unregister the specific image sizes that we did not need. We only needed three main crops: a thumbnail, a medium-sized grid image, and a large single-profile image. We did not need the extra six masonry and square crops that the default settings were forcing onto our server.
Here is the code I used to clean up the image generation process:
/**
* Unregister unnecessary theme image sizes to save server space and improve upload speeds
*/
add_filter('intermediate_image_sizes_advanced', 'optimize_maternity_theme_image_sizes', 99);
function optimize_maternity_theme_image_sizes($sizes) {
// List the image sizes registered by the theme that we do not want to use
$sizes_to_remove = [
'fertilys_post_masonry',
'fertilys_portfolio_grid',
'fertilys_service_carousel_thumb',
'fertilys_large_square',
'fertilys_extra_small'
];
foreach ($sizes_to_remove as $size) {
if (isset($sizes[$size])) {
unset($sizes[$size]);
}
}
return $sizes;
}Next, I tackled the query loop issue. I wanted to allow the site administrators to check a simple custom meta box (using a true/false field in Advanced Custom Fields) called doctor_on_leave. If this box was checked, that specific doctor would be automatically filtered out of the main team directory grid, without deleting their profile page.
I wrote a pre_get_posts filter to modify the main query whenever the doctor archive page or the custom team list was loaded:
/**
* Exclude doctors marked as 'on leave' from the main directory loop
*/
add_action('pre_get_posts', 'filter_active_doctors_in_directory');
function filter_active_doctors_in_directory($query) {
// Only run this on the front end, for the main query, and for our custom 'doctors' post type
if (!is_admin() && $query->is_main_query() && is_post_type_archive('doctors')) {
// We set up a meta query to check if the 'doctor_on_leave' custom field is NOT equal to 1
$meta_query = [
'relation' => 'OR',
[
'key' => 'doctor_on_leave',
'compare' => 'NOT EXISTS', // If the field hasn't been set yet, show the doctor
],
[
'key' => 'doctor_on_leave',
'value' => '1',
'compare' => '!=', // If set, it must not be equal to '1'
]
];
$query->set('meta_query', $meta_query);
// We also want to order the doctors alphabetically by their first name
$query->set('orderby', 'title');
$query->set('order', 'ASC');
}
}Implementing these two snippets solved our issues. The server stopped creating hundreds of useless image files, and the client had an easy, automated way to manage who appeared on the main clinic team page without having to rebuild Elementor sections every time someone took a vacation.
Day 4: Designing Content and Structuring for Trust (E-E-A-T)
On Day 4, I set aside my code editor and focused on the visual layout and the actual content structure. Since this is a medical site, we had to be incredibly careful about how information was presented. Google's Quality Rater Guidelines stress the importance of Experience, Expertise, Authoritativeness, and Trustworthiness (E-E-A-T).
If a site claims to offer medical advice about pregnancy or IVF but doesn't show who wrote the content, or if the content is written by a generic "admin" account, search engines will likely notice and rank the pages poorly.
I sat down with the clinic's lead nurse and their primary embryologist. We decided to structure the content pages to reflect their real, hands-on experience.
First, we customized the single post templates for the blog and the treatment informational pages. We made sure that every article about IVF, egg freezing, or prenatal vitamins had a clear author box at the top. This author box didn't just show a name; it linked to the doctor's detailed profile page, displaying their medical degrees, their board certifications, and their years of clinical experience.
We also designed the pages to use highly readable typography. When people are reading stressful medical information, they do not want to squint at tiny, light-gray text on a white background. I modified the global style sheet to ensure all body text had a clean, dark gray color (#2c3e50) and a comfortable font size of 18px with a 1.6 line height.
We replaced the generic stock photos from the theme demo with high-quality, real photos of the clinic. We showed the actual waiting room, the consultation offices, and the embryology lab. Real photos of a clean, welcoming environment build far more trust with an anxious patient than generic stock photos of models in clean white coats.
Day 5: Performance Optimization and Tuning CSS
By Day 5, the site was looking beautiful, and the content was structured correctly. But as we know, a beautiful website is useless if users click away because it takes too long to load. I spent the entire day tuning the site’s performance.
Elementor is a fantastic page builder for clients because they can easily edit text themselves later, but it is notorious for generating a massive amount of HTML code (often called "DIV soup").
To combat this, I went through the homepage section by section. I eliminated nested sections wherever possible. If I could achieve a layout using simple CSS flexbox columns instead of nesting three different inner section widgets, I rebuilt it using the cleaner approach.
Next, I set up our caching strategy. Since our server uses LiteSpeed, I installed the LiteSpeed Cache plugin. The default settings are okay, but to get a truly fast site, you have to spend time testing and tweaking the advanced options.
Here are the specific settings I configured:
- CSS Minification & Combination: I turned on CSS minification. However, I kept "CSS Combine" turned off. Combining all CSS files can sometimes cause rendering issues on modern HTTP/2 or HTTP/3 servers, where loading multiple small files in parallel is actually faster than downloading one massive combined file.
- Delayed JavaScript Execution: I set up a list of non-critical JavaScript files to delay until user interaction (like scrolling or moving the mouse). This included the Facebook pixel, Google Analytics, and the theme's custom slider scripts. This single step cut our "Total Blocking Time" on mobile tests by over 1.5 seconds.
- Critical CSS: I enabled the generation of Critical CSS. This ensures that the styling for the "above-the-fold" content (the top part of the homepage that the user sees first) is loaded immediately in the head of the document, preventing any ugly flashes of unstyled text.
Since some parts of our staging environment were running behind an Nginx reverse proxy, I also added a few custom headers to the Nginx configuration file to ensure static files were cached correctly by the browser:
# Custom caching rules for medical clinic static assets
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|webp|woff|woff2|ttf|otf)$ {
expires 365d;
add_header Cache-Control "public, no-transform, immutable";
access_log off;
log_not_found off;
# Enable Gzip compression for text-based assets
gzip_on;
gzip_types text/plain text/css application/javascript image/svg+xml;
}After implementing these adjustments and running the PageSpeed test again, the mobile score jumped from our initial 41 to an impressive 88/100, while the desktop score reached a near-perfect 97/100. The Largest Contentful Paint (LCP) was now under 2.2 seconds on a simulated mobile device, which is well within Google's recommended threshold.
Day 6: Contact Forms, HIPAA Compliance, and Security
On Day 6, we focused on the most important functional part of the website: how patients contact the clinic.
A fertility clinic is not a standard business. The inquiries they receive are highly sensitive. A patient might write about their medical history, their previous miscarriages, or their specific genetic concerns. In many countries, storing this type of Protected Health Information (PHI) on a standard WordPress database is a major legal risk under healthcare privacy laws like HIPAA.
To ensure compliance and protect patient privacy, we decided to handle form submissions carefully:
- No Health Data in the Database: We configured our contact forms so that they never save the content of the message field inside the WordPress database. If the site database were ever compromised by a hacker, there would be zero patient messages or health histories stored there to be stolen.
- Secure Transit: All form entries are sent directly to the clinic’s secure, external, HIPAA-compliant medical CRM via an encrypted API connection.
- Spam Prevention without Friction: We avoided using those annoying Google "reCAPTCHA" boxes where users have to click on traffic lights or crosswalks. These boxes are frustrating for anxious users and slow down page performance. Instead, we used a silent "honeypot" field and a lightweight server-side check.
I wrote a simple PHP cron job in our theme to clean up any temporary form data that might accidentally get stuck in our server's transient memory or session logs:
/**
* Daily cleanup task to clear temporary session transients and secure the server environment
*/
if (!wp_next_scheduled('weekly_clinic_database_cleanup')) {
wp_schedule_event(time(), 'weekly', 'weekly_clinic_database_cleanup');
}
add_action('weekly_clinic_database_cleanup', 'clear_expired_clinic_transients');
function clear_expired_clinic_transients() {
global $wpdb;
// Delete expired transients from the options table
$wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_timeout_%'");
$wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_%'");
// Clear out any old system error logs that might contain sensitive debugging data
if (file_exists(WP_CONTENT_DIR . '/debug.log')) {
unlink(WP_CONTENT_DIR . '/debug.log');
}
}This gave the clinic owners peace of mind. They knew that their website was a safe, secure pathway for patients to reach out, without exposing the clinic to massive legal liabilities.
Day 7: Structured Data, Local SEO, and Launching
On our final day, we prepared for launch. I focused entirely on search engine optimization and final checks.
For a local healthcare provider, Local SEO is everything. If someone in the city searches for "IVF clinic near me" or "best fertility doctor in [City Name]", we want our client’s site to appear at the very top of both the map pack and the organic search results.
To help Google's search crawlers understand exactly who we are, I wrote a custom Local Business Schema script. Instead of using a heavy SEO plugin to generate generic markup, I wrote a highly specific MedicalBusiness JSON-LD script and hooked it directly into the footer of our theme.
This script tells Google our exact address, our telephone number, our accepted payment methods, the languages our doctors speak, and links to our official social media profiles.
/**
* Inject structured Local Business Schema for the fertility clinic into the footer
*/
add_action('wp_footer', 'inject_clinic_local_business_schema');
function inject_clinic_local_business_schema() {
?>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "MedicalBusiness",
"name": "Hope Fertility & IVF Clinic",
"image": "https://staging.clinicgroupsite.com/wp-content/uploads/logo.png",
"@id": "https://staging.clinicgroupsite.com/#clinic",
"url": "https://staging.clinicgroupsite.com",
"telephone": "+1-555-0199",
"priceRange": "$$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "1200 Healing Waters Parkway, Suite 100",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.2672,
"longitude": -97.7431
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "08:00",
"closes": "17:00"
}
],
"medicalSpecialty": [
"ObstetricAndGynecologic",
"Endocrinology"
]
}
</script>
<?php
}After injecting the schema, I ran a final link-checking tool to make sure we did not have any broken links left over from the demo import. I also verified our SSL certificate to ensure it was configured correctly with an automatic redirect from HTTP to HTTPS.
With everything tested and running smoothly, I pointed the production domain name to our new staging server. The transition went without a hitch. The site was live, loading in under two seconds, and looking incredibly professional.
Looking Back: Pros and Cons of the Build
After spending a full week working deeply with this theme, I have a very clear picture of its strengths and weaknesses. Here is my honest developer review.
What I Liked (The Pros) Beautiful Niche Design: The layout is not just a generic corporate template. It uses soft, warm colors and clean typography that feel incredibly appropriate for a maternity and pregnancy center. Solid Gutenberg and Elementor Support: The theme works very well with Elementor, making it easy for the clinic staff to make simple updates to text and photos without needing my help every time. Clean Custom Post Types: The structure of the doctor and service profiles is logical and integrates smoothly with WordPress archives.
What Needs Improvement (The Cons) Image Bloat: By default, the theme registers far too many custom image sizes, which can quickly consume valuable server storage if you upload many photos. You will need to write custom filters (like the one I shared above) to keep your media library clean. Documentation Could Be Deeper: The documentation covers basic setup well, but it doesn't offer much help if you want to write custom queries or perform advanced developer optimizations.
Wrap-Up
Building a website in the pregnancy and fertility sector is all about building trust. By starting with a highly specialized foundation, optimizing our database and media uploads, and structuring our content around real human expertise, we managed to take a slow, outdated clinic site and turn it into a modern, fast, and secure portal.
It takes a bit of extra code and careful planning, but seeing a clean, fast site that helps anxious families connect with professional care makes the effort completely worth it.
