Genesis is a WordPress framework, not a theme. A Genesis site typically consists of three layers: the Genesis Framework parent theme, a Genesis child theme that holds all custom styles and template overrides, and content that has been built using PHP template files, custom post types, and shortcodes specific to Genesis or its associated plugins. This architecture means a Genesis-to-Kadence migration is not a simple theme swap — it is a controlled rebuild that must preserve content, SEO equity, and functionality while replacing the presentation layer entirely.
The most common Genesis sites you will encounter in your niches are older medical and church sites built on the StudioPress premium child themes — Minimum Pro, Executive Pro, Wellness Pro, and AgentPress Pro being the most frequent in Hampton Roads. These sites are often 5–8 years old, running outdated PHP, and built by developers who are no longer reachable. The client's content is valuable. The theme is not.
Never migrate in place on the live site. Always build on a staging environment and flip DNS only after full QA approval. A Genesis site with active patients or donors cannot have downtime. The staging-first approach is non-negotiable for this SOP.
Scope clarity for the client: Frame this as a rebuild, not an update. Manage expectations clearly: the new site will look dramatically better, load faster, and be much easier to maintain, but it will not be a pixel-for-pixel reproduction of the old site. Get written sign-off on this framing before starting.
1
Crawl the live site with Screaming Frog
Run a full crawl of the live Genesis site before touching anything. Export the results as a CSV. This is your ground truth for the migration.
From the crawl, record:
- Complete list of all URLs (pages, posts, custom post types, archive pages)
- All page titles and H1s — these inform your Kadence page structure
- All internal links — needed for redirect mapping
- All images — note which are in page content vs. set as featured images
- Any 404 errors already present on the live site — document these separately
- Response codes for every URL — flag any 301 chains already in place
Save the full CSV export as
[sitename]-crawl-pre-migration-[date].csv in the client's Google Drive project folder.
2
Document the Genesis child theme and plugins
Log into the live site wp-admin and record:
Theme layer:
- Genesis Framework version (Appearance → Themes)
- Child theme name and version
- Any custom CSS in the child theme's
style.css — copy the entire file
- Any PHP template files in the child theme — list and copy all
- Any Genesis hooks being used — search the child theme files for
add_action('genesis_'
Plugin inventory: Go to Plugins → Installed Plugins. For each active plugin record the name, version, and what it does on the site. Flag any Genesis-specific plugins (Simple Social Icons, Genesis Simple FAQs, Genesis eNews Extended, etc.) that will need Kadence-compatible replacements.
3
Screenshot every page at mobile and desktop
Use a browser extension or a tool like GoFullPage to screenshot every page of the site at desktop width and at 375px mobile width. Store in the client's project folder.
These screenshots serve two purposes: they are your design reference when building the Kadence equivalent, and they protect you if the client later claims "it looked different before." You want a documented record of exactly what the Genesis site looked like before you touched it.
Prioritise: homepage, about, all service pages, contact, blog index, one sample blog post.
4
Record baseline performance and SEO metrics
Before migration, run and save:
- PageSpeed Insights — mobile and desktop scores for homepage and one key service page. Save screenshots.
- Google Search Console — export the top 25 queries by clicks and the top 25 pages by impressions. This tells you which URLs are driving search traffic and must be preserved exactly.
- WAVE accessibility scan — homepage and contact page. Record error count.
- Current Google ranking — search the practice name + primary service + city. Screenshot the SERP position.
These baselines let you demonstrate improvement at the 30-day post-launch check-in and protect you if the client notices a temporary ranking fluctuation after migration.
5
Identify Genesis-specific shortcodes and widgets
Genesis and its child themes use proprietary shortcodes and widget areas that will break when the theme is changed. Search all page and post content for:
Common Genesis shortcodes to find and replace
[contact-form-7 ...]
[genesis_grid_loop ...]
[simple-social-icons ...]
[enews-ext ...]
[gfaq ...]
[testimonials ...]
Document every instance. For each shortcode, identify the Kadence Blocks equivalent (or plugin replacement) before starting the build. Having this list complete before you start prevents mid-build discovery of broken elements.
Create a full backup of the live site before any migration work begins — even though you will be working on staging, not the live site.
Use UpdraftPlus or your host's backup tool to create a full backup (files + database). Download it locally and store it in the client's Google Drive folder as [sitename]-full-backup-premigration-[date].zip.
This backup is your nuclear option if something goes catastrophically wrong. You need it locally, not just on the server, in case the server is also affected.
1
Create a staging copy of the live site
If using Flywheel or WP Engine: Both have one-click staging built in. Create the staging environment from the dashboard — it clones the entire live site (files + database) to a staging URL automatically.
If using other hosts: Use the Migrate Guru plugin (free) to clone the site to a staging domain. Set up a subdomain like staging.[clientdomain].com or use your host's provided staging URL.
Confirm the staging site is an exact match of the live site before proceeding. Check a few pages, the admin, and the database to verify the clone is complete.
2
Block staging from search engines
Immediately after creating staging, confirm search engine indexing is blocked.
Go to WordPress Settings → Reading and check "Discourage search engines from indexing this site." Also add a robots.txt disallow rule if your host does not handle this automatically.
A staging site indexed by Google before launch creates duplicate content issues that can damage the client's existing rankings. This takes 30 seconds and is not optional.
3
Install Kadence on staging
On the staging site:
- Go to Appearance → Themes → Add New → upload Kadence Theme
- Activate Kadence Theme (do NOT delete Genesis yet — keep both installed for reference)
- Install and activate Kadence Blocks Pro from your license dashboard
- Install and activate Kadence Theme Pro from your license dashboard
- Do not activate any Kadence starter templates — you are building from scratch to match the client's existing content structure
Genesis will still be installed but inactive. Keep it available until the Kadence build is complete in case you need to reference the original template files.
4
Deactivate Genesis-specific plugins on staging
On staging only, deactivate all Genesis-specific plugins that will not be carried forward. Do this one at a time and check the site after each deactivation to identify any layout dependencies.
Commonly deactivated: Genesis Simple Sidebars, Genesis Simple Hooks, Genesis Layout Extras, AgentPress Listings, Simple Social Icons (Genesis version).
Keep active for now: SEO plugin (Yoast or All in One SEO), contact form plugin, any content-generating plugins (events, custom post types), WooCommerce if present.
Note any plugin deactivations that cause visible breakage — these are dependencies you need to replace in the Kadence build.
Not all content from the Genesis site should be migrated as-is. A migration is an opportunity to audit quality, consolidate thin pages, and retire outdated content. Review every page against three criteria before deciding its fate.
| Decision | Criteria | Action |
|---|
| Migrate as-is |
Content is current, accurate, well-written, and the page has measurable search traffic or serves a clear user need. |
Copy content to Kadence page. Preserve the URL exactly. |
| Migrate with rewrite |
Content is structurally correct but outdated, thin, or written for a different era of SEO. Page URL has existing search equity. |
Rewrite the content in the new Kadence page. Keep the same URL. Flag for client review before publishing. |
| Consolidate |
Multiple thin pages covering overlapping topics. Common in old Genesis sites with dozens of near-identical service pages. |
Combine into one well-structured page. 301 redirect all old URLs to the consolidated page. |
| Retire with redirect |
Page has no search traffic, outdated content, or no longer reflects the practice's current services. |
Do not recreate. 301 redirect to the most relevant current page or to the homepage. |
| Delete |
Internal pages (thank-you pages, old campaign landing pages, test pages) with no inbound links and no search traffic. |
Remove. No redirect needed. Verify no inbound links first. |
Build your redirect map before building the new site. Create a spreadsheet with two columns: old URL and new URL. Every old URL that will change must have a destination. This spreadsheet drives the 301 redirect configuration in Step 6 and is the most SEO-critical deliverable in the entire migration.
Follow SOP-003 (Kadence Design Implementation) for the full build process. The steps below are Genesis-migration-specific additions and overrides to that SOP.
1
Set global typography to match or improve on the Genesis child theme
Genesis child themes use Google Fonts loaded via the child theme's
functions.php. Open the original child theme's stylesheet and
functions.php to identify the typefaces being used. In most StudioPress child themes these are declared as:
// In functions.php
add_action( 'wp_enqueue_scripts', 'theme_google_fonts' );
function theme_google_fonts() {
wp_enqueue_style( 'google-fonts',
'https://fonts.googleapis.com/css?family=...' );
}
In Kadence, set the equivalent font in Appearance → Kadence → Typography. You do not need to match the Genesis fonts exactly — if the client has approved new branding, use the project's designated fonts. If they want to preserve the existing look, match the fonts precisely.
2
Extract and apply brand colors from the Genesis child theme
Open the child theme's
style.css and find the primary color declarations. Most StudioPress child themes use a small set of accent colors. In the CSS look for:
/* Common locations in Genesis child themes */
a { color: #c3251d; }
.entry-title a { color: #333; }
.widget-title { color: #c3251d; }
button, .button { background-color: #c3251d; }
Copy these hex values into Kadence's global color palette (Appearance → Kadence → Colors). This ensures button colors, link colors, and accent colors match the original site by default before you make any intentional design improvements.
3
Rebuild header and navigation
Genesis headers are built using PHP template hooks and widget areas. In Kadence you rebuild this visually in the Header Builder (Appearance → Kadence → Header).
Map the Genesis header elements to Kadence equivalents:
- Genesis site title / logo → Kadence Logo block
- Genesis primary navigation menu → Kadence Primary Navigation block
- Genesis header widget area (phone number, social icons, etc.) → Kadence Header HTML or Button block
- Genesis secondary navigation (if present) → Kadence secondary nav row
Replicate the nav menu structure exactly — same menu items, same hierarchy, same labels — then make any design improvements.
Genesis footers are typically three-column widget areas with a narrow copyright bar below. Map each widget area's content to Kadence Footer Builder columns.
Common Genesis footer widgets to migrate:
- Text widget with address and phone → Kadence Footer HTML block
- Recent Posts widget → Kadence Recent Posts or custom query block
- Social Icons widget → Kadence Social Links block
- Newsletter signup widget → Replace with Mailchimp embed or equivalent
- Genesis copyright footer text → Kadence Footer Text block (update copyright year)
5
Replace Genesis widget areas in sidebars
Many Genesis child themes use right or left sidebar widget areas on interior pages. Kadence handles sidebars through its layout settings rather than Genesis hook areas.
For each page that previously had a sidebar: decide whether the sidebar serves a real purpose in the new design or whether a full-width layout is cleaner and more conversion-focused. In most healthcare sites the answer is full-width — sidebars in medical sites dilute the primary CTA and create visual clutter on mobile.
If the client insists on keeping sidebar content, migrate it to a Kadence Blocks sidebar column within the page layout rather than a WordPress widget area.
6
Replace Genesis shortcodes with Kadence Blocks equivalents
Work through the shortcode inventory from Step 1.5 and replace each one:
| Genesis shortcode / plugin | Kadence replacement |
|---|
| Simple Social Icons | Kadence Blocks → Social Links block |
| Genesis eNews Extended | Mailchimp embed or Kadence Form block + Mailchimp integration |
| Genesis Simple FAQs | Kadence Blocks → Accordion block |
| Contact Form 7 | Keep CF7 or migrate to Kadence Form block (preferred) |
| Testimonials widget | Kadence Blocks → Testimonials block |
| [genesis_grid_loop] | Kadence Blocks → Posts block (query loop) |
| AgentPress Listings CPT | Rebuild as Kadence custom post type or migrate to a standalone plugin |
| Genesis Layout Options per page | Kadence Layout settings per page (post meta box) |
1
Understand what to copy vs what to rebuild
Copy directly (safe): Plain text content — headings, body paragraphs, lists, contact information, service descriptions, staff bios, hours. These exist as clean text in the WordPress database and transfer without issues.
Rebuild rather than copy: Page layouts, column structures, hero sections, call-to-action blocks, image + text combinations. These were built using Genesis layout hooks and PHP templates. Copy-pasting their HTML output into Kadence will bring Genesis-specific classes, inline styles, and structural artifacts that will fight with Kadence's CSS.
The rule: copy the words, rebuild the structure.
2
Migrate images correctly
Images from the Genesis site are already in the WordPress media library and transfer automatically when you clone to staging. However:
- Featured images: Re-assign featured images on every post and page — Kadence uses different image sizes than Genesis child themes and the auto-assignment may not carry over cleanly.
- Hard-coded images in content: Images inserted directly into page content via the classic editor will migrate with the content. Check that URLs still resolve after migration.
- Background images set via Genesis hooks: These will not migrate automatically. Find them in the child theme CSS or custom CSS fields and re-implement as Kadence Row backgrounds.
- Optimise on the way in: Before inserting any image into the new Kadence pages, compress it through Squoosh (squoosh.app) and save as WebP. This is your opportunity to fix any unoptimised images from the Genesis era.
3
Handle blog posts and custom post types
Blog posts: If there are fewer than 20 posts, review each one and decide: migrate, consolidate, or retire. Posts with inbound links or search traffic must be migrated and their URLs preserved. Posts with neither can be retired with a redirect to a relevant category or the blog index.
More than 20 posts: Migrate all posts as-is using the staged database (they are already there from the clone). Set up the Kadence single post template to render them correctly. Then conduct a content audit post-launch to retire low-value posts incrementally.
Custom post types (Genesis AgentPress, Testimonials, etc.): These require individual handling. If the CPT data is still needed, the CPT plugin must remain active or the data migrated to a Kadence-compatible equivalent before going live.
4
Preserve and verify all internal links
After populating all Kadence pages with content, run the Broken Link Checker plugin on staging. Fix every internal broken link before proceeding.
If any page URLs changed during migration (consolidation or restructuring), update all internal links pointing to the old URLs to point to the new canonical destination. Do not rely on 301 redirects to handle internal links — update them directly. Internal link chains hurt performance and dilute PageRank flow.
★
Implement 301 redirects from your redirect map
Use the Redirection plugin (free) or your hosting platform's redirect manager to implement every redirect in your redirect map spreadsheet.
Implementation rules:
- All redirects must be 301 (permanent), not 302 (temporary)
- Redirect old URL → new URL, not old URL → homepage (unless the page is being retired with no relevant replacement)
- No redirect chains — if A redirected to B, and B is now being redirected to C, update A to redirect directly to C
- Test every redirect manually before go-live by visiting the old URL and confirming it lands on the correct new URL
# Test a redirect in browser
# Visit: staging-url.com/old-page-url/
# Expected: lands on staging-url.com/new-page-url/
# Check: browser address bar shows new URL (301 followed)
2
Migrate SEO metadata from Genesis to Yoast
Genesis child themes often use SEO plugins or the built-in Genesis SEO settings. The metadata stored there must transfer to Yoast.
If the Genesis site uses Yoast already: Yoast data is stored in wp_postmeta and transfers with the database clone. Verify a few pages to confirm title tags and meta descriptions are intact.
If the Genesis site uses All in One SEO (AIOSEO): Install the Yoast AIOSEO importer (built into Yoast Premium → Tools → Import) and run it on staging.
If the Genesis site uses Genesis SEO settings: These are stored in post meta under _genesis_title and _genesis_description keys. Export them using a database query or WP CLI and import into Yoast post meta fields. Flag this for manual migration if the site is small enough.
After migration, spot-check 10 pages in Yoast to verify title tags and meta descriptions transferred correctly.
Genesis sites typically have minimal schema markup — at most basic Organization or WebPage schema added via plugins or the child theme's
functions.php. This is an opportunity to significantly improve schema on the new site.
On the Kadence site, add:
- LocalBusiness (or MedicalOrganization / NGO) schema via Yoast Premium Local SEO
- BreadcrumbList schema (Yoast handles this automatically)
- FAQPage schema on any FAQ sections (Yoast or Kadence Accordion block)
- Any existing schema from the Genesis site that was in
functions.php — re-implement via Yoast rather than PHP
Validate using Google's Rich Results Test after staging is complete.
After all content is migrated and redirects are in place, regenerate the XML sitemap in Yoast (SEO → Tools → Regenerate sitemap, or it generates automatically).
Verify the sitemap includes all canonical URLs of the new site and excludes any old URLs that have been redirected or retired. Open staging-url.com/sitemap_index.xml and spot-check that page URLs match the new Kadence URL structure.
The sitemap will be submitted to Google Search Console immediately after go-live.
- Every page from the migration plan exists on the Kadence site
- Every page title, H1, and meta description is set and correct
- No placeholder content ("Lorem ipsum," "Page title goes here," "[CLIENT NAME]") remains on any page
- All images display correctly on mobile and desktop
- All internal links resolve correctly (no 404s from Broken Link Checker)
- Contact information (address, phone, hours) is accurate and consistent across all pages
- Staff page is current (no staff who have left, all new staff added)
- Copyright year in footer is current
- All 301 redirects tested and confirmed working on staging URL
- Yoast configured — title tags and meta descriptions on all pages
- Schema validated in Google Rich Results Test
- XML sitemap accessible at
/sitemap_index.xml and contains correct URLs
- Robots.txt on staging set to block indexing — will be reversed on go-live
- Google Analytics 4 tracking code installed and firing (use GA4 Realtime to verify)
- Search Console verification tag in place (ready to submit post-launch)
- SSL certificate confirmed active on the live domain (will carry over at DNS switch)
- PageSpeed score on staging — mobile 85 or higher before go-live
- Contact form tested — submission delivers notification email
- Booking tool (if applicable) tested end-to-end on mobile
- Donation form (if applicable) tested with a live test transaction and refunded
- All phone numbers are tap-to-call links
- All email addresses are mailto links
- Address links to Google Maps on mobile
- Navigation works on mobile (hamburger menu opens and closes, all items accessible)
- All external links open correctly (no broken outbound links to professional associations, insurance pages, etc.)
- Blog post template renders correctly on a sample post
- 404 page is styled and has navigation back to the homepage
- WP Rocket configured and caching active
- All images compressed and in WebP format
- Cloudflare CDN active on free tier
- Genesis Framework and old child theme deleted from Themes (not just deactivated)
- All Genesis-specific plugins deactivated and deleted
- WordPress, Kadence, and all remaining plugins on latest versions
- Wordfence or Solid Security active
- UpdraftPlus daily backups configured to off-site storage
- wp-admin uses non-default username
- Two-factor authentication enabled on admin account
Client sign-off required before go-live. Send the client the staging URL and a written sign-off request. They must confirm in writing (email is sufficient) that all content is accurate and approved before DNS transfer. Specifically ask them to verify: staff list, service descriptions, contact details, hours, and any medical or legal copy. Record the date and time of their approval.
1
Choose your go-live window
Go live between 6am and 8am on a Tuesday, Wednesday, or Thursday. Avoid Mondays (high traffic from weekend backlog), Fridays (people are less likely to be available if something goes wrong over the weekend), and any day the client has a high-traffic event (annual gala, major fundraising campaign, advertising go-live).
DNS propagation typically takes 5–30 minutes with most managed hosts, but can take up to 48 hours with some registrar configurations. The site will be live for most visitors well within the first hour.
If using Flywheel or WP Engine: Use the platform's built-in domain management to point the custom domain to the staging site. The platform handles SSL provisioning automatically.
If managing DNS at the registrar: Update the A record (or CNAME for subdomain) to point to the new host's IP address. Lower the TTL to 300 seconds (5 minutes) at least 24 hours before the switch to ensure fast propagation. Restore TTL to 3600 after propagation confirms.
Keep the old Genesis site on the old host until propagation is confirmed complete. Do not shut down the old server until the new site is live and confirmed working.
3
Immediately after DNS propagation
Within the first 30 minutes of confirmed propagation:
- Uncheck "Discourage search engines" in WordPress Settings → Reading
- Verify robots.txt at yourdomain.com/robots.txt — confirm it is not blocking all crawlers
- Submit the XML sitemap to Google Search Console
- Request indexing of the homepage in Google Search Console → URL Inspection
- Test 5 random redirects on the live domain (not staging) to confirm they work
- Test the contact form on the live domain
- Check GA4 Realtime to confirm tracking is firing on the live domain
- Update the Google Business Profile website URL to the live domain
First 48 hours: Check Google Search Console for crawl errors daily. Any spike in 404 errors indicates a redirect that was missed or misconfigured. Fix immediately.
First week: Monitor rankings for the top 10 search terms documented in the pre-migration baseline. A temporary dip of 1–3 positions is normal during re-indexing. A sustained drop of more than 5 positions on a high-traffic page after 7 days warrants investigation — check that the page's URL, title tag, H1, and content are intact.
At 30 days: Compare GA4 sessions, bounce rate, and conversion events against the pre-migration baseline. Run PageSpeed again and compare to the pre-migration score. Run the case study template.
Common Genesis child themes in Hampton Roads medical and church niches:
| Child theme | Typical niche | Key patterns to watch for |
|---|
| Wellness Pro | Medical, alt health | Full-width image homepage sections, testimonials widget, 4-column footer, custom widgetized areas |
| Executive Pro | Medical, nonprofit | Three-column services section, custom page templates, prominent sidebar on interior pages |
| Ministry Pro | Church | Events widget, sermon CPT, multi-column homepage widgets, video embed widget areas |
| AgentPress Pro | Rare in your niches | AgentPress Listings CPT — needs full custom migration plan |
| Minimum Pro | Any niche (minimal) | Relatively clean — few custom hooks, easiest to migrate |
| Custom child theme | Any niche | Requires full PHP audit before starting — no predictable pattern |
Genesis hook system → Kadence equivalent reference:
| Genesis hook | What it does | Kadence equivalent |
|---|
genesis_header | Renders entire header | Kadence Header Builder |
genesis_nav_bar | Primary navigation | Kadence Header Builder → Navigation block |
genesis_before_content | Content inserted above main | Kadence Row at top of page template |
genesis_entry_header | Post/page title area | Kadence Page Header (Appearance → Kadence → Page Header) |
genesis_entry_content | Main content area | WordPress content editor (Kadence Blocks) |
genesis_sidebar | Sidebar widget area | Kadence Blocks column layout or removed (full-width) |
genesis_footer | Renders entire footer | Kadence Footer Builder |
genesis_after_footer | Scripts / tracking below footer | WordPress → Theme File Editor → footer.php or plugin |
WP-CLI commands useful during migration:
Search and replace staging URLs in the database
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables
Export Genesis SEO meta to CSV for Yoast import
wp post list --post_type=page --fields=ID,post_title --format=csv | while IFS=, read id title; do
echo "$id,$title,$(wp post meta get $id _genesis_title),$(wp post meta get $id _genesis_description)"
done
Verify all redirects return 301
while read old new; do
code=$(curl -o /dev/null -s -w "%{http_code}" -L "$old")
echo "$code | $old -> $new"
done < redirect-map.txt