WordPress Interview Questions

WordPress.org provides the free, self-hosted software that you download and install on your own web hosting, giving full control over themes, plugins, and configuration. WordPress.com is a hosted service built on that same software, offering managed hosting with varying levels of control depending on the plan, with more restrictions on plugins and customization at the free and lower tiers.

A theme controls the visual appearance and layout of a WordPress site, including templates for different types of pages, like the homepage, blog posts, and archives. Switching themes changes how content looks and is arranged without changing the underlying content itself.

A plugin is a package of code that adds new functionality to a WordPress site without modifying WordPress's core files, ranging from simple features like a contact form to complex systems like e-commerce or membership management. WordPress's large plugin ecosystem is one of the main reasons it's so widely adopted.

The admin dashboard is the backend interface where site administrators log in to manage content, install themes and plugins, configure settings, and manage users. It's typically accessed at a site's /wp-admin URL.

A post is a piece of content typically associated with a date and often organized into categories and tags, commonly used for blog entries that appear in reverse chronological order. A page is meant for static, standalone content, like an About page or a Contact page, that isn't part of a chronological stream.

A custom post type is a content type beyond WordPress's built-in posts and pages, like 'Products,' 'Portfolio Items,' or 'Events,' registered either through a plugin or custom code. It lets WordPress manage structured content that doesn't fit naturally into the default post or page model.

A category is a broad, typically hierarchical way to organize content into major sections of a site, like 'News' or 'Reviews,' while a tag is a more specific, non-hierarchical keyword used to label individual pieces of content, like 'javascript' or 'interview-tips.' Posts are usually assigned to one or a few categories but can have many tags.

A widget is a small block of content or functionality, like a search box, a list of recent posts, or a calendar, that can be added to a theme's designated widget areas, like a sidebar or footer, usually through a drag-and-drop interface. Widgets let non-technical users add functionality to specific areas of a site without writing code.

The Loop is the core PHP code structure that WordPress uses to display posts, iterating through a set of matching posts (based on the current page or query) and outputting each one's content according to the theme's template. Understanding the Loop is fundamental to WordPress theme development since nearly every template that displays post content relies on it.

The wp-content directory holds everything that isn't part of WordPress's core software, including themes, plugins, and uploaded media files. It's the directory site owners and developers primarily interact with, and it's what typically needs to be backed up along with the database to fully preserve a site's customizations.

WordPress core is the base software itself, providing the fundamental content management functionality and the framework that themes and plugins build on top of. A theme controls appearance and layout, and a plugin adds new functionality, and both are designed to be added, removed, or swapped without modifying core files directly.

A shortcode is a small bracketed tag, like [gallery] or [contact-form], that content editors can insert directly into post or page content to trigger specific dynamic functionality without writing code. Plugins commonly register shortcodes to let non-technical users embed features like forms or galleries easily.

The WordPress REST API is a built-in interface that lets external applications and JavaScript code interact with WordPress data (posts, pages, users, and more) over HTTP using JSON, without needing direct database access. It's what powers many modern JavaScript-driven WordPress front ends and third-party integrations.

A hook is a way to insert custom code at a specific point in WordPress's execution without editing core files, and comes in two types, actions, which let you run custom code at a certain point, and filters, which let you modify data as it passes through. Hooks are the foundation of how themes and plugins extend and customize WordPress behavior.

An action hook lets you execute custom code at a specific point during WordPress's execution, like sending a notification email when a post is published, without expecting anything back. A filter hook lets you intercept and modify a piece of data as it passes through WordPress, like changing the excerpt length, and must return the (possibly modified) value.

functions.php is a special theme file that runs automatically whenever the theme is active, commonly used to register menus and widget areas, enqueue scripts and stylesheets, add custom hooks, and define other theme-level functionality. It effectively acts like a plugin scoped to that specific theme.

A child theme inherits the functionality and styling of a parent theme while allowing you to override or add specific templates and styles in its own separate files. It's the recommended way to customize an existing theme, since it keeps your customizations safe from being lost when the parent theme is updated.

Editing a parent theme directly means any customization is lost the next time that theme receives an update, since updates typically overwrite the theme's files entirely. Using a child theme instead isolates your customizations in separate files that updates to the parent theme won't touch.

WordPress stores data in a set of MySQL (or MariaDB) tables, with wp_posts holding posts, pages, and custom post type entries, wp_users and wp_usermeta holding user data, wp_options holding site-wide settings, and wp_postmeta holding additional custom data attached to individual posts. Plugins commonly add their own tables or store data in wp_options and wp_postmeta rather than modifying WordPress's core table structure.

A permalink is the full, permanent URL structure used for a specific post, page, or other content on a WordPress site, and its overall format (like whether it includes the date or just the post name) is configurable through WordPress's settings. Changing permalink structure after a site has existing content and inbound links can break those links unless redirects are set up.

An excerpt is a short summary of a post, either written manually or generated automatically by truncating the content, commonly shown in blog listing pages or archives. Full content is the entire post body, typically shown when a visitor clicks through to view that specific post on its own page.

Gutenberg is WordPress's block-based content editor, introduced as the default editor, where content is built from individual blocks, like paragraphs, images, and columns, rather than a single large text field. It replaced the older classic editor and is designed to make building more visually structured layouts easier without needing custom code for every layout variation.

A block is a discrete, self-contained piece of content or layout, like a paragraph, an image, a button, or a custom plugin-provided block, that can be added, rearranged, and configured independently within the editor. Blocks are the fundamental building unit that the Gutenberg editing experience is organized around.

A static front page shows fixed content you've specifically chosen, commonly used for business or portfolio sites where the homepage isn't meant to show a chronological post feed, while a blog posts page shows a chronological listing of recent posts. WordPress lets you configure separate pages for each, which is common for sites that want a custom homepage but still maintain a blog elsewhere on the site.

The media library is the central place where all uploaded images, videos, documents, and other files are stored and managed, letting content editors reuse the same uploaded file across multiple posts and pages rather than uploading duplicates. It also handles generating multiple resized versions of uploaded images for use in different contexts.

WordPress has built-in user roles, like Administrator, Editor, Author, Contributor, and Subscriber, each with a different predefined set of capabilities controlling what that user can do, from managing the entire site down to just reading content. Plugins can add custom roles or capabilities to fit more specific permission needs beyond the defaults.

Multisite is a WordPress feature that lets a single WordPress installation run and manage multiple separate sites, sharing the same core files, themes, and plugins while each site keeps its own distinct content and, optionally, its own set of active plugins and theme. It's commonly used by organizations that need to manage many related sites, like a network of regional sites, from one central installation.

SEO (Search Engine Optimization) in WordPress refers to configuring content and site structure to rank well in search engine results, commonly assisted by plugins like Yoast SEO or Rank Math that help manage things like meta descriptions, sitemaps, and readability suggestions for individual pieces of content. WordPress's clean, semantic markup and flexible permalink structure also give it a reasonably strong SEO foundation out of the box compared to some other platforms.

A backup is a saved copy of a site's files and database that can be restored if something goes wrong, like a failed update, a hack, or accidental content deletion. Since WordPress sites combine both files (themes, plugins, uploads) and a database (posts, settings, users), a complete backup needs to capture both, beyond just one or the other.

A staging site is a copy of a live WordPress site used to test changes, like plugin updates or new features, in an isolated environment before applying them to the actual production site. It reduces the risk of a change breaking the live site that real visitors are using.

Caching stores a precomputed version of a page or a piece of data so it can be served quickly on future requests instead of regenerating everything (database queries, PHP processing) from scratch every time. WordPress caching commonly happens at multiple levels, page caching, object caching, and browser caching, often managed through a dedicated caching plugin.

Shared hosting provides general-purpose web server space shared across many customers with minimal WordPress-specific optimization, while managed WordPress hosting is specifically tuned for running WordPress, often including built-in caching, automatic updates, and specialized support for WordPress-specific issues. Managed hosting typically costs more but reduces the amount of server-level maintenance a site owner needs to handle themselves.

A plugin conflict happens when two or more active plugins interfere with each other, often because they modify the same functionality in incompatible ways or load conflicting versions of a shared library, resulting in errors or broken functionality. Troubleshooting typically involves deactivating plugins one at a time to isolate which combination is causing the issue.

Updating WordPress core updates the base software itself, updating a theme updates the templates and styling code, and updating a plugin updates that specific piece of added functionality, and each can be updated independently of the others. Keeping all three current is important for security, since outdated software is one of the most common ways WordPress sites get compromised.

The Developer Handbook (which succeeded the older Codex as the primary reference) is WordPress's official documentation covering how to build themes, plugins, and use core functions correctly. It's the standard first reference for a developer trying to understand how a built-in WordPress function or feature is meant to be used.

I'd register the custom post type through code, either directly or through a lightweight plugin, specifying its supported features, labels, and whether it should be publicly queryable, and pair it with custom fields, using either a fields plugin or native custom field registration depending on the project's needs. I'd think ahead about how that data will actually be queried and displayed in templates, since a custom post type structure that's awkward to query becomes a recurring pain point.

I'd start by profiling where the actual time is going, database queries, uncached page generation, unoptimized images, or too many render-blocking scripts and stylesheets, rather than guessing. Common fixes include implementing page and object caching, optimizing and lazy-loading images, minimizing the number of active plugins, and addressing any inefficient database queries a poorly coded plugin or theme might be running.

I'd look for an appropriate action or filter hook the plugin exposes, which most well-built plugins provide specifically to allow this kind of customization, and add my custom code in the theme's functions.php or a small custom plugin rather than touching the plugin's files directly. Editing a plugin's files directly means losing those changes the next time it's updated, so relying on hooks is the maintainable approach.

I'd keep WordPress core, themes, and plugins updated consistently, remove any unused themes or plugins entirely rather than just deactivating them, enforce strong passwords and limit login attempts, and use a security plugin or web application firewall for an added layer of protection. I'd also make sure file permissions are set correctly and that the wp-config.php file, which holds database credentials, isn't publicly accessible.

I'd export the full database and copy the wp-content directory (themes, plugins, uploads) to the new host, update the wp-config.php database credentials for the new environment, and carefully handle any hardcoded URLs in the database using a proper search-and-replace tool rather than a naive find-and-replace that could corrupt serialized data. I'd test thoroughly on the new host, ideally with a staging URL, before pointing the live domain's DNS at the new server.

I'd weigh the specificity of the design requirements against the time and cost of custom development, since a well-regarded existing theme combined with a child theme for customization can get a professional-looking site live much faster and cheaper than starting from scratch. I'd lean toward a fully custom theme when the design is highly specific to the brand, when performance requirements demand a lean codebase without a general-purpose theme's extra bloat, or when a project needs functionality that off-the-shelf theme customization can't reasonably achieve.

I'd use wp_enqueue_script and wp_enqueue_style hooked into wp_enqueue_scripts rather than hardcoding script and link tags directly into the template files, which lets WordPress manage dependencies, avoid duplicate loading, and handle versioning for cache busting correctly. Hardcoding assets directly bypasses WordPress's dependency management and can cause conflicts with plugins that load the same shared libraries.

I'd validate and sanitize all submitted data on the server side regardless of any client-side validation, use WordPress's nonce system to protect against cross-site request forgery, and check user capabilities before processing any privileged action. I'd never trust that data arriving from a form is safe just because the form itself has client-side validation, since that can always be bypassed.

I'd typically build a small custom plugin that handles the API integration, using WordPress's built-in HTTP API functions for making requests rather than raw PHP curl calls, and cache the API responses using transients so the site isn't hitting the external API on every single page load. I'd also handle the case where the external API is slow or unavailable gracefully, so a third-party outage doesn't take down the whole site.

I'd enable WordPress's debug mode to surface the actual PHP error rather than a blank screen, check the server's error logs directly if debug mode isn't accessible, and narrow down the cause by deactivating plugins and switching to a default theme one at a time if needed. A white screen is almost always a fatal PHP error somewhere, often from a plugin or theme conflict or a resource limit being exceeded, and getting the actual error message is the key first step.

I'd build those customizations through a child theme and custom plugins rather than editing the premium theme's files directly, so future theme updates don't wipe out the client's paid-for customizations. I'd also document what's been customized clearly, since premium theme updates occasionally change internal structure in ways that can break customizations built on top of specific implementation details.

I'd use WordPress's built-in role and capability system to define new roles or add specific capabilities to existing ones, rather than trying to hack around the permission system with ad hoc conditional checks scattered through custom code. This keeps access control centralized and consistent, and makes it easier to audit exactly what each role can and can't do.

I'd favor server-side rendering for content that's important for initial page load speed and SEO, since search engines and slower connections benefit from getting fully rendered HTML immediately. I'd favor client-side fetching via the REST API for highly interactive features where the added JavaScript complexity is justified by a genuinely more dynamic, app-like user experience.

I'd keep theme and custom plugin code in a version control system like Git, generally excluding WordPress core files and third-party plugins from the repository since those are better managed as dependencies, and use a consistent local development environment across the team to avoid environment-specific bugs. I'd also establish a clear process for handling the database separately from code, since database content changes constantly in ways that don't fit neatly into a typical Git workflow.

I'd use modern, efficient image formats where supported, implement lazy loading so images below the fold don't load until needed, and make sure WordPress's automatic responsive image sizing is actually serving appropriately sized images rather than always the full original file. Many of these optimizations are handled well by a good image optimization plugin, but I'd still verify the actual output rather than assuming the plugin is configured optimally by default.

I'd audit each plugin's actual usage and necessity, checking with the client about anything unclear, and deactivate and remove anything genuinely unused, since every active plugin adds potential security surface area and performance overhead. I'd do this carefully on a staging site first, since removing a plugin that turns out to be a hidden dependency for something else can break functionality unexpectedly.

I'd wrap all user-facing text strings in WordPress's translation functions, like __() or _e(), with a consistent text domain matching the theme, rather than hardcoding plain text directly into templates. This lets the theme be translated into other languages later using standard WordPress translation tooling without needing to touch the template code itself.

I'd apply the update first on a staging environment that closely mirrors production, test the site's core functionality and anything specifically related to that plugin, and check for any reported compatibility issues with the plugin's changelog or support forum before proceeding. For business-critical sites I'd also make sure a recent backup exists and is verified as restorable before applying any update directly to production.

I'd use WordPress's block editor tooling, typically React-based, to register a custom block with the specific fields and controls the client needs, keeping the block's editing experience intuitive for non-technical content editors. I'd weigh this against simpler alternatives, like custom fields with a template, for cases where the full complexity of a custom block isn't really justified by the actual need.

I'd assume a genuine compromise until proven otherwise and take the site offline or into maintenance mode while investigating, checking for unfamiliar admin users, unexpected files in the wp-content directory, and malicious code injected into theme or plugin files. I'd restore from a known clean backup where possible rather than trying to manually clean an infected site, since fully removing all traces of a compromise by hand is difficult to do with full confidence.

I'd weigh how much of the original theme's structure remains intact versus how much has effectively been overridden or worked around through years of incremental customization, since a theme that's been patched repeatedly can end up harder to maintain than a clean rebuild would be. I'd also factor in whether the underlying design itself is due for a refresh anyway, since that's often a natural point to justify the cost of starting clean rather than continuing to build on a fragile foundation.

I'd separate code deployment from content changes clearly, deploying theme and plugin code changes through a controlled process while letting content publishing continue independently on production without needing to go through the same pipeline. I'd also make sure any database schema changes a deployment introduces are handled carefully, since content created on production between when staging was last synced and when the deployment happens needs to be preserved, not overwritten.

I'd weigh the client's actual technical comfort and how much ongoing control they genuinely want against the added performance overhead and potential lock-in that many page builder plugins introduce. For a client who truly needs to make frequent layout changes without developer help, a well-chosen page builder can be worth that tradeoff, while for a design that's meant to stay fairly stable, native theme development usually gives a cleaner, faster result.

I'd use WordPress purely as a content management backend, exposing content through the REST API or a GraphQL layer, with a separate JavaScript framework handling the actual front-end rendering and user experience. I'd carefully weigh this decision though, since headless WordPress adds real architectural complexity, editorial workflow challenges around previewing content, and loses some built-in functionality that traditional theme development gets for free.

I'd map out the existing data model and custom functionality thoroughly before writing any migration code, identify which parts map cleanly to native WordPress structures versus needing custom post types or custom tables, and build and test the migration scripts against a full copy of production data rather than a small sample that might not surface edge cases. I'd plan for a staged rollout with a clear rollback plan, since a migration this significant carries real risk of unexpected issues surfacing only under production-scale data.

I'd structure the plugin with clear separation of concerns, keeping data access, business logic, and presentation reasonably distinct rather than mixing everything together in large procedural files, and follow WordPress coding standards and hook conventions so future developers familiar with WordPress can navigate it without learning an entirely custom pattern. I'd also add proper activation, deactivation, and uninstall handling so the plugin behaves predictably across its full lifecycle, beyond just when it's actively running.

I'd start with detailed server-level and application-level monitoring to correlate the issue's timing with specific traffic patterns, plugin activity, or resource spikes, rather than trying to reproduce it manually on a much lower-traffic staging environment where the issue might not appear at all. I'd also check for a poorly optimized database query that only becomes a genuine problem at production data volume and concurrency, which is a common cause of intermittent, hard-to-reproduce performance problems.

I'd carefully decide which plugins should be network-activated (available to every site) versus activated individually per site, based on which functionality genuinely needs to be consistent across the network versus which needs site-specific flexibility. I'd also plan for how theme and plugin updates get tested and rolled out across the whole network, since a bad update can potentially affect every site at once rather than just one.

I'd look at concrete signals, consistently slow response times even after standard caching optimizations, frequent resource limit errors, or traffic that's clearly outpacing what the current hosting tier can comfortably handle. I'd recommend a move to dedicated or more scalable infrastructure, potentially with a CDN and managed database, once those signals show the current setup is a genuine constraint rather than jumping to a bigger infrastructure investment ahead of need.

I'd introduce automated testing for the custom code specifically, unit tests for business logic that doesn't depend on the full WordPress environment, and integration tests using WordPress's testing framework for functionality that does depend on it. I'd prioritize test coverage on the highest-risk, most business-critical custom functionality first, since achieving full coverage across an entire large WordPress codebase all at once usually isn't a realistic near-term goal.

I'd configure custom roles and capabilities matched to the actual editorial workflow, writers who can draft but not publish, editors who can review and approve, and use a workflow or editorial calendar plugin to manage content through those stages clearly. I'd also think about how revision history and commenting on drafts fit into that workflow, since a large content team needs visibility into where each piece of content stands without relying on communication entirely outside the CMS.

I'd focus on database performance specifically, since large product catalogs and high order volume put real strain on WordPress's database structure, optimizing queries, adding appropriate indexes, and potentially offloading search to a dedicated search service rather than relying on WordPress's default database-driven search at scale. I'd also make sure caching strategy accounts for the dynamic, personalized nature of e-commerce, since naive full-page caching can accidentally show one customer's cart or personalized pricing to another.

I'd assess each critical plugin's maintenance history, developer reputation, and how actively it's updated, since a poorly maintained plugin handling something business-critical is a real operational risk. For genuinely critical functionality I'd consider whether custom, in-house code gives more control and reduces dependency risk, weighed against the real cost and time of building and maintaining that functionality ourselves instead of relying on an existing plugin.

I'd stage updates through a lower-risk subset of sites on the network first, monitoring for issues before rolling the same update out network-wide, rather than applying updates to every site simultaneously. I'd also make sure network administrators have a fast, well-rehearsed way to roll back a network-activated plugin update if it causes unexpected problems, since a bad network-wide update can affect every site at once.

I'd weigh WordPress's genuine strengths, a huge ecosystem, strong content management workflow, broad hiring pool of people who know it, against whether the organization's specific needs, like extremely high custom application logic or requirements far outside typical content management, are starting to genuinely strain what WordPress does well. For most content-driven organizations WordPress remains a very sound choice even at significant scale, and I'd be cautious about recommending a platform change without clear, specific evidence the current platform is a real constraint.

I'd quantify the specific benefit driving the consideration, like needing to power multiple front ends (web, mobile app, kiosk) from the same content, or performance requirements that a fully custom front-end framework serves meaningfully better than traditional server-rendered WordPress. I'd be honest about the real added complexity headless architecture introduces, particularly around content preview and editorial experience, so the decision reflects the true full cost, beyond just the appeal of a more modern-sounding architecture.

I'd establish a review process assessing security history, maintenance activity, code quality, and licensing before a plugin is approved for organization-wide use, maintaining a living catalog of pre-approved plugins so most day-to-day decisions don't need a fresh review each time. I'd reserve deeper scrutiny for plugins touching sensitive functionality, like payment processing or user data handling, where the stakes of a poorly vetted choice are much higher.

I'd inventory which sites have custom code or plugins most likely to be affected by the change, prioritize testing those first on staging environments, and stage the rollout starting with lower-risk sites to build confidence before touching the most business-critical properties. I'd also maintain close communication with the teams responsible for each site, since they often have context about fragile custom functionality that isn't visible from a purely technical audit.

I'd centralize the things that carry organization-wide risk, security patching cadence, hosting infrastructure standards, plugin vetting, while leaving teams real latitude over content strategy, theme customization, and day-to-day site management within those guardrails. I'd expect this balance to need periodic revisiting as the organization and its portfolio of sites grow and change.

I'd treat that concentration of knowledge as a genuine operational risk, similar to any single point of failure, and prioritize documenting the plugin's functionality and cross-training additional developers on it, rather than letting the risk persist until that developer is unavailable during an actual incident. I'd track this explicitly rather than treating it as an informal concern that never gets addressed.

I'd establish centralized monitoring and alerting for signs of compromise across all managed properties, a clear incident response runbook defining who does what when a compromise is suspected, and a communication plan for notifying affected stakeholders appropriately depending on the severity and nature of the incident. I'd also run periodic incident response drills, since a runbook that's never been exercised often has gaps that only surface during an actual real incident.

I'd prioritize based on business criticality combined with current fragility, a high-traffic revenue-generating site held together by outdated, poorly maintained custom code deserves investment well before a lower-stakes site with the same issues. I'd favor incremental modernization for most sites over full rebuilds, reserving full rebuilds for cases where the existing codebase is genuinely beyond reasonable repair and the business case for a full replacement is clear.

I'd evaluate whether the functionality in question is really core to how the organization differentiates itself versus a commodity capability, like payment processing or advanced search, that a dedicated service now handles significantly better and more reliably than a custom WordPress solution reasonably can. For commodity functionality where a mature, well-supported service exists, I'd generally favor integrating with that service over continuing to invest in custom in-house code.

I'd frame ongoing maintenance, updates, security monitoring, performance tuning, as a continuous cost of keeping web properties reliable and safe, similar to how they'd think about maintaining any other critical business infrastructure, rather than a one-time project that's ever fully finished. I'd back that framing with concrete evidence, like past incident history or the real cost of an outdated, vulnerable site being compromised, so the conversation stays grounded rather than abstract.

I'd weigh the operational efficiency gains of consolidation, shared maintenance, consistent plugin management, against the real risk of a shared point of failure, since an issue with the shared WordPress core or a network-activated plugin can affect every site in the network at once. I'd favor consolidation when the sites genuinely share enough common needs and ownership to justify that shared risk, and would keep sites separate when their requirements or stakeholders are different enough that shared infrastructure would create more friction than it saves.

I'd set up automated, frequent backups stored in a separate location from the primary hosting, verified periodically through an actual test restore rather than just trusting the backup process ran successfully. I'd also document and periodically rehearse the full recovery procedure, since discovering gaps in a recovery plan during an actual outage is far more costly than finding them during a planned drill.

I'd look beyond raw plugin count at how tightly interdependent the plugins have become, whether critical business functionality depends on plugins with weak maintenance track records, and whether the combination has made routine updates genuinely risky rather than routine. A large but well-chosen, well-maintained plugin stack is a manageable performance tradeoff, while a fragile web of interdependent, poorly maintained plugins is a structural risk that needs deliberate remediation.

I'd translate the technical risk into business terms they already track, the cost and reputational damage of a public security breach, lost traffic and revenue from poor site performance, and the growing difficulty of hiring developers willing to maintain a badly outdated codebase. I'd pair that framing with a concrete, staged investment plan so the conversation moves toward a decision rather than just raising a concern they can't act on.

I'd make code review and architectural discussion a regular part of the team's process, specifically asking questions about maintainability and update-safety, beyond just whether a feature works today, and share concrete examples from the organization's own history where a quick shortcut created real problems later. I'd also model that thinking myself in my own contributions, since developers tend to absorb what leadership actually does more than what they say.

I'd anchor the vision in durable principles, strong separation between custom code and third-party dependencies, consistent security and performance practices, rather than committing rigidly to a specific architectural pattern that might not fit future needs, given how much the broader WordPress and web development landscape continues to shift. I'd revisit the vision periodically with input from both development and content teams, since the right specific approach should evolve even as the underlying principles stay fairly stable.

I'd treat it as an urgent forcing function to capture what remains of that knowledge quickly, prioritizing documentation and cross-training on the highest-risk, highest-traffic functionality first rather than trying to document everything at once. I'd also use the gap as an opportunity to finally formalize practices, coding standards, deployment processes, that had been living as informal tribal knowledge, since that's usually overdue by the time a departure like this happens.

I'd prioritize based on business criticality combined with current fragility, a high-traffic, revenue-critical site held together by outdated, poorly maintained code deserves investment well before a lower-stakes site with the same issues. I'd build that prioritization with genuine input from the teams and stakeholders who actually depend on each site, since they usually understand the real risk and value better than a purely metrics-driven view from outside would show.

I'd make raising a concern about a site's security posture or performance genuinely valued rather than treated as slowing down delivery, and back that by giving teams real room to address what gets flagged rather than only paying lip service to caring about it. Leadership visibly prioritizing this in practice, beyond just in words, matters more than any written policy on its own.

I'd avoid letting critical knowledge concentrate in one or two individuals by deliberately rotating ownership of key sites and plugins and requiring documentation and cross-review as a standard part of any significant change, even when that's slower in the short term. I'd track which sites or systems have a single point of failure in terms of who understands them and treat closing that gap as an explicit, tracked priority.

I'd frame this as a continuous investment in keeping the organization's web presence reliable, secure, and adaptable, similar to how they'd think about maintaining any other critical shared capability, rather than a cost that should shrink to zero once the initial sites are built. I'd back that framing with concrete evidence, like incident history or the growing cost of unaddressed technical debt, so the conversation stays grounded rather than abstract.

I'd identify the strongest WordPress practitioners already spread across different teams and give them a structured way to share what they know, through internal documentation, office hours, or a shared library of vetted internal tools and plugins, rather than trying to centralize all WordPress development under one team. I'd measure success by whether sound practices actually spread and show up in other teams' work, beyond just that group's own output.

I'd look for concrete, sustained evidence that the current architecture is a real constraint on specific business goals, rather than reacting to industry trend pieces or a single compelling case study from a very different kind of organization. A shift of this magnitude carries real retraining and migration cost, so I'd want that evidence to be strong and well-documented before recommending it broadly.

I'd make sure site health metrics, security posture, performance, uptime, are genuinely visible in how teams and their leaders are evaluated, beyond just feature delivery speed, and pair that with realistic timelines that don't force a constant choice between doing it right and hitting a date. Incentive structure tends to matter more than any individual code review, since people and teams respond over time to what's actually rewarded.

I'd break the roadmap into phases with concrete, business-visible milestones, since a plan that only pays off years out tends to lose support long before it's finished. For engineering teams I'd be explicit about what's changing and why at each phase, and for business leadership I'd tie each phase to a tangible outcome like improved site performance or reduced security incident rate, so the investment stays justified throughout.

I'd bring in outside expertise for a time-bounded specialized need, like a large migration or a design overhaul requiring skills the team doesn't currently have, while making internal knowledge transfer an explicit part of that engagement so the organization isn't left dependent on the agency for ongoing maintenance. For long-term platform ownership I favor building internal capability, since a capability this central to daily operations benefits from people who stay and carry institutional context forward.