In this post, I will show you what to do in the first 24 hours for a hacked WordPress site.

It usually starts with a message. A customer says your site redirected them somewhere strange. Google shows “This site may be hacked” under your listing. Your host emails to say your account is sending spam.

The urge is to start deleting files right away. Don’t. Cleaning before you’ve contained the problem is how sites get reinfected a week later. Panic also destroys the evidence you need to find out how the attacker got in.

I’ve built WordPress websites since 2005 and worked in SEO for more than 18 years. Over that time I’ve cleaned up enough hacked WordPress sites to know that the order matters more than the tools. Here’s the order.

First, confirm it’s really a hack

Not every strange problem is a hack. An expired domain, a broken plugin update or a full disk can look alarming too. These signs point to a real compromise:

Table 1: Common signs of a hacked WordPress site.

A quick test: search Google for site:yourdomain.com and scroll through the results. Pages you didn’t create, especially in another language or about pills, replica goods or casinos, mean someone else is publishing on your site.

Hours 0 to 1: Contain the damage

The goal in the first hour is to stop the harm spreading to your visitors, and to keep a record of what happened.

Take the site offline for visitors

Put the site into maintenance mode, or ask your host to restrict access to your own IP address while you work. A hacked site can redirect visitors to scams or download malware onto their devices. Protecting them comes first.

Back up the hacked site

Take a full copy of the files and the database before you change anything. It sounds backward, but it’s important. That copy shows when files were modified and what was injected, and it’s what you’ll study to find the way in.

Tell your host

Most hosts have seen this before. They can check server logs, tell you whether other sites on your account are affected, and sometimes clean the infection for you. If your host has already suspended the account, they’ll explain what they need to restore it.

Hours 1 to 4: Lock down every way in

Assume the attacker has a password, a hidden admin account or both. Close every door before you clean, or they’ll walk straight back in.

1. Change every password. That means your hosting account, SFTP or FTP, the database, every WordPress administrator and the email account tied to the site. Use a password manager and make each one unique.
2. Reset the WordPress security keys. The keys and salts in wp-config.php sign everyone’s login cookies. Replacing them with fresh values from the official WordPress generator logs out every session, including the attacker’s.
3. Check the user list. Go to Users and look for administrators you don’t recognize. Note the usernames and creation dates before you delete them, because they help date the attack.
4. Turn on two-factor authentication for every admin account, if it isn’t on already.

Hours 4 to 12: Clean the site

This is the longest phase. There are two ways to do it, and the right one depends on your backups.

Option 1: Restore a clean backup

If you have a backup from before the infection, restoring it is usually the fastest and safest path. The hard part is knowing which backup is clean. Use the hacked copy you took earlier to find the oldest modified or injected file, then restore a backup from before that date.

One warning: a restore brings back whatever let the attacker in. If an outdated plugin caused the hack, the restored site has the same hole. That’s why the next phase matters.

Option 2: Clean in place

Without a clean backup, you rebuild the site from trusted parts. When a small business calls me as a Sydney WordPress developer after a hack, this is the route we usually end up on, because the backups either don’t exist or were taken after the infection.

Replace what you can

Delete and reinstall WordPress core, every plugin and every theme from their official sources. Don’t trust the existing copies, even if they look normal. If you have WP-CLI access, these commands compare your files against the official versions:

wp core verify-checksums

wp plugin verify-checksums –all

Check the places attackers hide

• PHP files inside wp-content/uploads. That folder should hold images and documents, not code.
• The .htaccess and wp-config.php files, for injected redirects or code.
• The database, for script tags inside posts, widgets and the site URL settings.
• Scheduled tasks, both WordPress cron events and the server’s own cron jobs.

A security scanner such as Wordfence, Sucuri or MalCare helps here. Treat its report as a starting point, though, not proof the site is clean.

Hours 12 to 24: Recover and close the hole

Find the entry point

Cleaning without knowing how they got in is guesswork. The usual causes are an outdated or abandoned plugin, a “nulled” premium plugin downloaded from an unofficial site, a reused password, or another compromised site on the same hosting account. Your server access logs, read alongside the dates from your hacked backup, often point straight to it.

Update and remove

Update WordPress, every plugin and every theme. Delete anything you don’t use, including inactive themes. Replace any plugin that hasn’t been updated in a year or more.

Ask Google to lift the warning

Open Google Search Console and check the Security issues report. Once the site is clean, request a review there. Reviews can take from a day to a few weeks. Spam pages the attacker created should return a 404 or 410 status, so Google drops them from its index over time.

Check whether customer data was exposed

If the site stored customer details, such as form entries, accounts or orders, work out whether they were accessed. Breach notification rules vary by location. Under the EU’s GDPR, for example, certain breaches must be reported to the regulator within 72 hours. If personal data may be involved, get proper advice quickly.

Five mistakes that make a hack worse

Most of the long, painful cleanups I’ve seen came from one of these.

1. Restoring the latest backup without checking its date. If the infection is three weeks old, last night’s backup is infected too.
2. Deleting the hacked files before copying them. You lose the trail that shows how the attacker got in, so you can’t close the hole.
3. Changing only the WordPress password. Attackers often come back through hosting, SFTP or database access, which a WordPress password change doesn’t touch.
4. Trusting one scanner’s “all clear”. Scanners miss custom backdoors. Check the uploads folder, the user list and the database yourself.
5. Reinstalling the same nulled plugin. Pirated premium plugins are one of the most common ways malware gets onto WordPress sites. Buy the license or replace the plugin.

The next two weeks

A cleaned site isn’t finished on day one. Reinfection usually comes from a backdoor that was missed. For at least two weeks:

• Run a security scan every day.
• Check the user list and the uploads folder for anything new.
• Watch Search Console for new spam pages or security alerts.
• Keep daily backups going, and store copies away from the hosting account.

How to stop it happening again

Prevention is mostly routine. These five habits close most of the doors attackers use on small business sites:

1. Update WordPress, plugins and themes at least weekly, and remove anything you don’t use.
2. Give every person their own login, with a unique password and two-factor authentication.
3. Keep daily backups stored away from your hosting account, and test a restore once a quarter.
4. Use a firewall, either from your host, a security plugin or a service such as Cloudflare.
5. Buy premium plugins and themes only from their official sources.

My take

Most hacked WordPress sites I see weren’t targeted. They were found. Automated tools scan the web for known plugin flaws, weak passwords and forgotten admin pages, and a small business site is as likely to be hit as a big one.

The good news is that the fix is routine work: updates, unique passwords, two-factor login and backups you’ve actually tested. None of it is glamorous. All of it is cheaper than spending the first 24 hours after a hack working through this list.

INTERESTING POSTS

In ths post, I will show you why employee ID badges still matter in a zero trust world.

Cybersecurity strategies have evolved dramatically over the past decade. Organizations now invest heavily in multifactor authentication, endpoint protection, cloud security, identity governance, and Zero Trust architectures. Yet while businesses strengthen their digital defenses, one fundamental aspect of organizational security often receives less attention: physical employee identification.

Even the most sophisticated cybersecurity infrastructure cannot fully protect an organization if unauthorized individuals can freely enter restricted areas, access unattended workstations, or move through sensitive facilities without being challenged.

This creates an important connection between cybersecurity and physical security. Organizations must understand not only who can access their digital systems but also who is physically present in their workplaces.

Employee identification badges, when combined with appropriate access controls and security policies, remain a practical component of a comprehensive security strategy.

Why Physical Identity Still Matters in a Digital Security Environment

Modern organizations increasingly operate through cloud applications, remote connections, and distributed workforces. As a result, security discussions often focus on protecting digital identities rather than managing physical access.

However, offices, data centers, warehouses, healthcare facilities, and other workplaces still contain valuable assets that require protection.

An unauthorized individual entering a restricted area may gain access to network equipment, confidential documents, company devices, or unattended computer systems.

These risks cannot be addressed exclusively through firewalls or endpoint security software.

Physical security policies help establish boundaries around facilities and sensitive areas, while employee identification procedures make it easier to distinguish authorized personnel from visitors.

A consistent identification system also supports employee accountability and helps security personnel recognize individuals who may require additional verification.

The objective is not to replace digital security controls but to extend organizational security practices into the physical workplace.

Employee ID Badges as a First Layer of Physical Identification

Employee identification badges provide a visible way to associate individuals with an organization.

A typical badge includes an employee’s photograph, name, job title, and company branding. Some organizations also include department identifiers or other information relevant to workplace operations.

When employees consistently display identification, colleagues and security personnel can more easily recognize authorized staff members.

This becomes particularly valuable in larger organizations where employees may not personally know everyone working in the building.

Businesses can use standardized ID badges to establish consistent visual identification across departments, facilities, and employee groups.

For example, an organization might use different badge designs to distinguish permanent employees, contractors, and visitors.

These visual distinctions can support security awareness and make it easier for staff to identify individuals who may need assistance or verification.

However, an important distinction must be maintained: a visible badge is not proof that the person carrying it currently has authorization to enter a restricted area.

Badges can be lost, stolen, duplicated, or retained after employment ends.

For that reason, visual identification should be treated as one security layer rather than a standalone access control mechanism.

How Employee Identification Fits Into Zero Trust Security

Zero Trust has become an influential approach to cybersecurity because it challenges the assumption that users or devices should automatically be trusted based on their location within a network.

Instead, access decisions should be based on appropriate verification, authorization, and contextual security controls.

Although Zero Trust architectures primarily address access to digital resources, their underlying principles can inform physical security practices as well.

For example, an employee who is authorized to enter a corporate office should not automatically receive access to every server room, storage facility, or restricted department.

Physical access permissions should reflect legitimate business requirements.

An identification badge may help establish who an individual claims to be, while an electronic access control system determines whether the associated credential is authorized for a particular location.

Additional verification may be appropriate for highly sensitive facilities.

Organizations should also review access permissions when employees change roles or leave the company.

This approach reinforces the broader principle of granting access according to operational necessity rather than assuming that all employees require identical privileges.

Importantly, implementing employee badges does not itself establish Zero Trust compliance. Badges are supporting tools within a much larger security framework.

RFID, NFC, and Traditional Photo Badges: Understanding the Differences

Not all employee identification cards provide the same capabilities.

Selecting the appropriate technology requires understanding how different badge types operate and what security functions they can support.

Traditional photo ID badges

Standard photo badges are primarily designed for visual identification.

They typically display an employee’s name, photograph, title, and organization.

These credentials are useful for workplace recognition, visitor differentiation, and maintaining consistent professional identification.

However, they do not inherently provide electronic authentication or access control.

RFID and proximity cards

Radio-frequency identification technology allows compatible readers to communicate with electronic credentials without requiring physical contact.

Certain RFID and proximity cards are commonly used with building access control systems.

Depending on the technology, these systems can associate a credential with specific doors, access schedules, or facility permissions.

However, RFID is a broad category that includes technologies with substantially different security characteristics.

Some older proximity systems rely on relatively weak credential identification methods and may be vulnerable to cloning or unauthorized duplication.

Organizations should evaluate the security capabilities of their specific card technology and reader infrastructure rather than assuming all RFID credentials provide equivalent protection.

NFC-enabled cards

Near Field Communication is a short-range contactless technology used in applications such as mobile interactions, information exchange, and certain credential systems.

NFC-enabled cards may support different functions depending on the chip, software, and compatible reader.

Some NFC implementations are suitable for secure applications, while simple NFC tags may only store publicly readable information.

Therefore, NFC capability alone should not be interpreted as evidence that a card provides secure authentication.

Businesses should select credential technologies based on documented compatibility, security requirements, and the capabilities of their existing infrastructure.

The Security Risks of Lost, Stolen, and Unreturned Badges

One of the most common weaknesses in physical credential management is the failure to promptly address lost or unreturned identification cards.

An employee may misplace a badge during travel, leave it in a public location, or forget to return it after leaving the organization.

If the badge is connected to an electronic access system and remains active, it may present an unnecessary security risk.

Organizations should establish clear procedures requiring employees to report missing credentials promptly.

For electronically enabled badges, administrators should be able to revoke or suspend associated access permissions through the appropriate access control platform.

Replacement badges should be issued only after verifying the employee’s identity and following established administrative procedures.

Employers should also discourage employees from lending identification cards to colleagues or allowing unauthorized individuals to use their credentials.

Regular reviews of active access credentials can help identify outdated assignments and reduce the number of unnecessary permissions.

Physical badges without electronic access capabilities should also be managed carefully because they may be used to impersonate employees or create a misleading appearance of authorization.

Why Employee Offboarding Is a Critical Security Process

Employee onboarding receives considerable attention from HR and IT departments, but offboarding is equally important from a security perspective.

When an employee leaves an organization, administrators typically need to disable system accounts, revoke application permissions, recover company equipment, and update relevant records.

Physical identification credentials should be included in this process.

A departing employee may still possess a badge displaying the company’s name and logo, even after digital accounts have been disabled.

If the badge also functions as an electronic access credential, failure to deactivate it could leave physical access permissions active.

This creates an avoidable gap between digital identity management and facility security.

A coordinated offboarding checklist should address both physical and digital credentials.

Human resources, IT, and security personnel should have clearly assigned responsibilities so that access changes occur promptly and consistently.

For example, an employee departure notification can trigger separate tasks for disabling digital accounts, revoking building access, and collecting identification cards.

Organizations should also document exceptions, such as situations where a former employee retains limited authorized access for a defined business purpose.

The objective is to ensure that access permissions reflect current employment status and legitimate operational requirements.

Centralized Badge Management and Identity Lifecycle Security

As businesses expand, managing employee identification across multiple offices can become increasingly complex.

Different departments may use inconsistent badge templates, maintain separate employee records, or follow different procedures for issuing replacements.

These inconsistencies can create administrative inefficiencies and make it harder to maintain reliable identification standards.

A centralized approach to employee identification and physical access control can help organizations coordinate badge issuance and physical credential workflows across locations.

Online badge design and management tools can support consistent employee photographs, names, titles, and organizational branding without requiring each location to maintain separate design processes.

For example, a company operating ten regional offices may establish approved identification templates while allowing authorized administrators to prepare badges for employees at their respective locations.

Centralized physical badge management can also support consistent procedures for new hires, departmental transfers, and replacement requests.

However, organizations should distinguish between badge production systems and enterprise access control platforms.

A system used to design and order identification cards does not automatically manage electronic door permissions, digital identities, or security authentication.

Where these capabilities exist in separate systems, organizations should establish clear processes to keep employee information and credential status appropriately coordinated.

The Human Factor: Building a Security-Conscious Workplace

Technology alone cannot prevent every physical security incident.

Employees play an important role in maintaining secure workplaces by following identification policies, reporting suspicious activity, and respecting access restrictions.

For example, an employee may hold a secure door open for an unfamiliar individual out of courtesy, unintentionally allowing that person to bypass access controls.

This behavior, commonly associated with tailgating or unauthorized entry, illustrates why physical security awareness matters.

Organizations should train employees to recognize identification requirements and follow established procedures when encountering unfamiliar individuals.

However, security policies should avoid encouraging confrontational behavior.

Employees should know when to contact reception, facility security, or designated supervisors rather than attempting to personally investigate potentially unsafe situations.

Clear visitor identification, consistent badge use, and well-communicated access procedures can help make security expectations easier to understand.

The goal is to establish a workplace culture in which physical security becomes a routine operational responsibility rather than an occasional concern.

Building a Practical Employee Identification Security Policy

Organizations seeking to strengthen physical identification procedures should begin with a clear written policy.

This policy should define who receives identification credentials, what information appears on badges, and how cards are issued or replaced.

It should also establish procedures for temporary employees, contractors, visitors, and individuals working across multiple locations.

Where electronic access credentials are used, organizations should document how permissions are assigned, reviewed, and revoked.

Regular audits can help identify active credentials that no longer correspond to authorized personnel.

Businesses should also evaluate the information displayed on employee badges.

Names, photographs, and professional roles are often sufficient for visual identification. Unnecessary personal information, sensitive employee identifiers, or confidential internal details should generally be excluded.

Finally, organizations should ensure that badge management procedures remain practical for employees and administrators.

Security controls that are unnecessarily complicated may encourage workarounds, while clear and consistent processes are more likely to be followed.

Conclusion: Physical Identification Remains Relevant in Modern Cybersecurity

As cybersecurity continues to evolve, organizations must avoid overlooking the relationship between digital and physical security.

Cloud protection, multifactor authentication, and Zero Trust architectures are essential components of modern security strategies, but they do not eliminate the need to manage physical access and employee identification.

Well-designed identification badges help organizations distinguish employees from visitors, maintain consistent workplace standards, and support broader security procedures.

When combined with appropriate electronic access controls, employee training, and coordinated onboarding and offboarding processes, they contribute to a more comprehensive approach to organizational protection.

For businesses managing distributed workforces, multiple facilities, and changing employee populations, standardized badge management also offers practical administrative benefits.

Ultimately, effective security depends on more than protecting digital accounts. It requires understanding who has access to organizational resources, whether those resources exist in the cloud, on a corporate network, or behind a physical door.

INTERESTING POSTS

For developers, AI APIs for developers are useful when they turn a model capability into a dependable product feature. That requires more than sending a prompt and displaying the answer. The application must define the task, control data flow, validate output, handle outages, measure cost, and monitor whether the result helps users. The model is one dependency inside a larger software system.

The best design begins with the user’s job. A team building document search needs to retrieve relevant source material and enforce permissions before a language model writes a response. A voice interface needs to manage audio capture, transcription, model latency, and playback. A coding assistant needs boundaries around repository access and generated code. Each use case calls for a different combination of models and controls.

Start with a product requirement, not a model name

Describe the feature in terms a product and engineering team can test. “Make support better” does not define success. “Draft a response using the approved return policy and show the source section to the agent” is more precise. It identifies the inputs, expected output, and the human who can review the result.

Write success criteria before choosing a model. For a drafting tool, those criteria might include factual consistency with the source, correct tone, response time, and the share of drafts accepted with minor edits. For data extraction, schema validity and field accuracy may matter more. Use criteria that correspond to product behavior rather than model reputation.

Collect representative examples and review their permissions. If the dataset contains customer or business information, use synthetic or redacted examples for early experiments. Later testing with real data should follow the organization’s privacy and security process.

Choose the API boundary

An application can call one provider directly, use a managed gateway for several model providers, or run a gateway in its own infrastructure. A direct connection can be simplest when one model meets the product’s needs. A gateway can reduce integration and billing work when a feature needs multiple models. A self-hosted layer can help with network control but requires an operations owner.

The API boundary should preserve the capabilities the feature uses. If the application depends on streaming, tool calls, structured outputs, image input, or a specific safety setting, confirm that the selected route supports them. A nominally compatible API can still differ in edge cases or optional parameters.

When evaluating a common access layer, developers can review a service such as AI APIs for developers. The site currently describes one API and account for a range of models and tools. Treat that as an evaluation starting point; check the current model catalog, SDK support, endpoint schemas, pricing, and privacy documentation against the feature’s requirements.

Design for output uncertainty

Model responses are generated and may vary. Do not use a natural-language answer as a substitute for deterministic application logic. If the output changes an account, sends a payment, or performs an irreversible action, require a separate authorization and validation path.

For structured data, define a schema, parse the response, and reject values outside the allowed set. For summaries or recommendations, ground the answer in approved documents where possible and show the source references. For tool use, validate each argument and enforce permissions in application code before executing it.

Set maximum input and output sizes. Restrict the number of conversation turns or tool calls. Add a total workflow deadline so a chain of model calls cannot keep a request open indefinitely. For long tasks, use a job queue and return a status to the user rather than holding a web connection open.

Keep data and credentials under control

Trace every part of a request: user message, system instruction, retrieved document, file, tool output, and metadata. The content actually sent may be larger than the visible prompt. Remove fields that the model does not need, and ensure retrieval systems enforce user permissions before adding documents to context.

Use server-side credentials stored in an approved secret manager. Scope API keys to the needed operations if the provider supports it, rotate them, and avoid exposing them in browser code or mobile bundles. A browser application should send requests to a backend service that can enforce authorization, rate limits, and input validation.

Review data retention and processing terms for each service in the request path. A gateway may add another processor, so assess it alongside the upstream model provider. Decide what can be logged, who may access those logs, and when they are deleted. Operational telemetry can often use request IDs, model names, status, duration, and usage without storing raw content.

Make reliability a feature requirement

A user-facing AI feature needs a defined behavior for slow or unavailable services. Set a timeout that reflects user expectations. Use bounded retries for transient errors and avoid repeating invalid requests. If a fallback model is available, verify that its output fits the same schema and meets the feature’s minimum quality bar.

Show a useful state when the model cannot respond: allow the user to retry, offer a non-AI path, or save work for later. Avoid presenting a partial or stale answer as if it were complete. The product should distinguish an empty response, a provider error, and an application validation failure in telemetry.

Monitor both system behavior and user outcomes. System signals include errors, latency, rate limits, usage, and fallback frequency. Product signals include edits, acceptance, completion, escalation, or correction. A low error rate does not prove the feature is useful, while user dissatisfaction can reveal prompt or retrieval problems that infrastructure metrics miss.

Evaluate with the real workflow

Build a small regression set from representative tasks. Score the outputs against a rubric that reflects the feature’s purpose. Keep edge cases and negative examples. Repeat the tests when the prompt, model, endpoint, or retrieval configuration changes.

For model comparisons, use the same inputs and record the exact model identifier, prompt version, response time, usage, and result. Review failures rather than relying only on an aggregate score. If the application uses tools or retrieval, test the complete loop, because an excellent model response cannot compensate for a missing document or incorrect permission check.

After deployment, sample outputs in a privacy-conscious way and collect user feedback. Define an owner who can respond to a model update, provider incident, or cost spike. Keep a rollback path and a feature flag so the team can disable or redirect the feature without a full application release.

Keep costs understandable

Calculate cost per completed user task. Include prompt history, retrieved context, generated output, tools, retries, and any multimodal steps. Cost per token is one input to the calculation, not the whole picture. A model that requires several follow-up calls can cost more than a stronger model that finishes in one pass.

Set budgets at the workflow or account level where possible. Alert on unexpected usage, cap user-controlled input, and prevent untrusted callers from turning an API key into an open proxy. If the product offers several models, explain which one a user is selecting and whether a more capable model has a different cost or response time.

A concise design checklist

Before release, confirm that the feature has a narrow task definition, an evaluation set, data minimization, secure credentials, output validation, bounded timeouts, safe failure behavior, and cost monitoring. Document who owns model changes and how to roll back. Test the full experience with realistic user inputs, not only an API playground prompt.

AI APIs make capabilities accessible, but reliable products come from the surrounding engineering. When the application controls data flow, validates results, monitors cost, and gives users a graceful path through failure, model access can become a useful part of the product rather than an unpredictable side effect.

FAQ

What is the first step in building with an AI API?

Define one user task and how success will be measured before selecting a model or endpoint.

Can a model API enforce application permissions?

No. The application must check access rights and validate actions independently of model output.

What metrics matter after release?

Track system behavior such as latency, errors, and usage alongside product outcomes such as completion, edits, and escalations.

INTERESTING POSTS