WP-C common mistakes
WP-C · Understand the traps and how to avoid them.
Writing page copy and markup directly in the browser editor and never validating the saved output, so broken HTML, unescaped ampersands, or raw shortcode remnants only surface after publish.
The block editor preview usually renders content forgivingly, so candidates assume the editor is the source of truth and skip checking the front-end rendering and the theme template that actually outputs the content.
What to do instead
Before finalizing any content task, save, view the published page logged out, and inspect the generated markup for unclosed tags, double-escaped entities, and shortcodes that failed to render; treat the rendered front end, not the editor canvas, as the artifact being graded.
Choosing a plugin or theme by reputation or by the first search result instead of reading its changelog, last-updated date, tested-up-to version, and support history.
Candidates optimize for getting the feature working quickly and treat plugin selection as a trivial step, forgetting that abandoned or bloated plugins are the most common cause of later site failures.
What to do instead
Apply a fixed checklist to every plugin decision: recent release, compatible with the current core version, active support, no bundled unrelated features, and a stated exit path; justify the choice in terms of maintenance burden rather than features alone.
Diagnosing a white screen, 500 error, or broken layout by editing live files and guessing, instead of capturing the error and isolating the cause systematically.
Under time pressure candidates reach for the fastest visible action, and shared hosting often hides PHP errors, so they cannot see the real message and start changing things blindly.
What to do instead
Establish a repeatable triage order: enable debug logging in a staging copy, read the actual fatal error and file path, then bisect by switching to a default theme and disabling plugins one at a time; only then change code, and document the root cause.
Conflating users, roles, and capabilities, for example granting the Administrator role when the task only requires Editor-level publishing rights, or assuming a role change affects only one site in a network.
Roles are familiar labels, so candidates reason about them by name rather than by the granular capabilities they bundle, and they forget that roles are stored per site and can be modified by plugins.
What to do instead
Translate every access requirement into the minimum capability needed, verify which role supplies it, and check whether any plugin has altered the role map; on multisite, confirm the scope of the change before applying it.
Publishing a content migration or bulk update without a tested restore path, relying on an untested export file or a backup that was never verified.
Backups feel like a formality, and candidates assume that a completed export means a usable restore, so they discover the gap only after data loss.
What to do instead
Before any bulk change, take a snapshot, restore it into a scratch environment, and confirm the restored site matches the source; keep the restore step in the runbook and state the rollback trigger explicitly.
Answering a client or stakeholder scenario with a feature list instead of a scoped recommendation with effort, cost, risk, and measurable outcome.
Technical candidates default to describing what is possible, and the business framing is the part they practiced least, so the answer reads as enthusiasm rather than professional judgment.
What to do instead
Structure every business answer as situation, constraint, options with trade-offs, recommendation, and success metric; quantify in hours or budget ranges and name the risk being accepted, even when the numbers are estimates.
Treating content structure as decoration, dumping all page text into a single block or heading levels chosen for visual size rather than document outline.
The editor makes visual styling easy and semantic structure invisible, so candidates optimize for how the page looks in the editor rather than how it reads to assistive technology and search engines.
What to do instead
Build pages from a heading outline first, use one top-level heading per page and nested levels in order, mark up lists, tables, and quotes with their semantic blocks, and reserve styling for the stylesheet rather than the markup.
Ignoring the legal and editorial side of content work: reusing images without checking licensing, omitting alt text, and publishing claims without a review step.
The task appears purely technical, and stock imagery from search results looks free, so rights and accessibility obligations are never consciously considered.
What to do instead
Keep a small pre-publish gate: confirm the license and attribution for every asset, require descriptive alt text for informative images and empty alt for decorative ones, and route factual or regulated claims through an identified reviewer.
Ignoring performance and caching when delivering a content or configuration change, then attributing slow pages to hosting instead of to the change just made.
Caching layers make results non-deterministic, so a change appears not to apply or appears to break something, and candidates react by clearing caches repeatedly instead of reasoning about the stack.
What to do instead
Map the caching layers in play, purge deterministically after each change, and measure before and after with the same tool; when a change seems not to apply, verify which layer is serving the response rather than purging everything.
Managing a project without a written definition of done, so scope creeps through small favors and the delivery slips without anyone noticing until the deadline.
Small requests feel harmless individually and refusing them feels unhelpful, so the boundary is never stated and the original estimate silently becomes invalid.
What to do instead
Write acceptance criteria and an explicit out-of-scope list at kickoff, log every new request against them, and respond to additions with a revised estimate and a trade-off decision rather than silent acceptance.