Gambling Links in a WordPress Database: Audit wp_posts and wp_options

Google results show gambling links on one article, but the page in the dashboard looks different. A file check finds no unfamiliar script, and someone suggests running a query to delete every matching term from the database. That can be dangerous: values in wp_posts or wp_options may mix unauthorized content with legitimate articles, plugin settings, and PHP serialized data.

The short answer: use the database as evidence to inspect with read-only queries, not as a place to guess deletion commands. Record the exact domain or anchor that was observed, make a protected export before changing anything, use the site’s real table prefix, search wp_posts, wp_postmeta, and wp_options, then compare each result with its URL, author, revision, logs, and owning plugin. Remove or restore only records that have been verified, and close the process that wrote them. Google classifies content placed without permission as hacked content, but a site’s response still needs to follow its own evidence (Google Search spam policies).

This article focuses on database triage, not every kind of WordPress cleanup. If you find unknown accounts, redirects, recurring files, or server changes, treat them as part of an incident and use our hacked-website recovery guide. If the issue is ordinary comment or user-generated spam, first distinguish that context using our guide to WordPress comment and post spam.

Preserve evidence and export the database safely

Before running a query, record the sample URL, title/snippet, destination domain, time, request that exposed the link, and user who reported it. Do not open gambling, phishing, or malware links to confirm their destination. If the site handles transactions or personal data, notify the owner and host according to the incident process. Record whether the link appeared in HTML, the dashboard, a sitemap, search results, or only for a particular referrer or device.

Ask an administrator to export the database using an approved hosting or WP-CLI process. wp db export writes a SQL dump; see the official wp db export documentation. Store the file outside the webroot with restricted access or encrypted media—not in the site’s public download folder, open email, or Git. Understand the backup location and retention policy; a dump may contain emails, orders, tokens, and private content.

When possible, restore the dump to a private staging copy that is not publicly reachable and perform the search there. Do not make your first cleanup test against the production database. Record the snapshot time and time zone; database, logs, and hosting panels may use different zones. If immediate containment is necessary, ask the host to take a snapshot first under its procedure.

Understand the structure before typing a query

wp_posts and wp_options are common names, not guarantees. Site owners can change the table prefix, and multisite may use per-site suffixes. Confirm the prefix from the protected configuration or ask the host; do not paste an example query without adapting it. wp_posts stores several WordPress object types, including posts, pages, attachments, revisions, and custom post types. Review each result by post_type and post_status.

Start with the specific domain or anchor in your evidence, not broad words such as “casino”, “bet”, or “slots”. Those terms may appear in legitimate news, catalogs, analysis, or user content. This query is a read-only example for a database copy; replace wp_ with the actual prefix and malicious.example with a verified host:

SELECT ID, post_type, post_status, post_title, post_name
FROM wp_posts
WHERE post_content LIKE '%malicious.example%';

Limit the output fields. Do not print the full post_content into a shared terminal log; it can contain customer information or unsafe markup. Open matching records through a private dashboard or controlled staging inspection, record the ID and owner, and compare them with the public URL reported.

Check posts, options, and metadata separately

For wp_posts, inspect the title, slug, type, status, author, date, and revisions. A link can be injected into an existing article without creating a new URL. Content rendered by a plugin may come from wp_postmeta, a custom table, or a shortcode rather than post_content. Therefore, an empty query does not prove the database is clean. Review plugin-created objects and confirm that their owners recognize them.

For wp_options, plugins store settings, and some values may be serialized. Search for the verified host or a specific indicator on a database copy, but limit the results so secrets are not printed. This example returns option names and value lengths only:

SELECT option_name, LENGTH(option_value) AS value_bytes
FROM wp_options
WHERE option_value LIKE '%malicious.example%';

A matching option is not automatically malicious; it could be a URL list, stale cache, or legitimate configuration. Record its name, owning plugin, relevant autoload state, modification evidence if available, and context before deciding. Avoid putting complete option values in a report if they contain secrets or internal settings.

Use WP-CLI wp db query only for reviewed queries, with authorized access to the intended database copy. The official wp db query reference explains that it executes SQL against the configured database. Avoid unreviewed write commands or code copied from a forum; a mistaken query can change many records without an easy recovery path.

Distinguish search results from the root cause

Finding a domain in post_content does not tell you who added it. Compare the record with revisions, login logs, author accounts, form/REST API requests, plugin updates, cron events, and the time that files or options changed. Check whether a legitimate integration created the content. Spam may be inserted through a compromised legitimate account; a familiar author name does not prove the activity was authorized.

If the host is absent from the fields you checked, consider links assembled by a theme, plugin, custom post type, widget, template, serialized option, comment, cache, or rewrite rule. Inspect a sample response and server request on staging. Make sure a CDN/cache is not serving a stale copy; purge it after the source is known and fixed, not to conceal symptoms. If the link appears only for a crawler or certain visitors, compare user-agent, referrer, login state, and device under controlled conditions.

If findings return after a record is edited, look for the writer: automation plugin, scheduled event, API credential, administrator account, file, system cron, deployment, or malware. Stop repeating database changes until you isolate that writer. Check core/plugin files with suitable checksums, accounts, Application Passwords, and host logs. If you cannot tell whether an option stores required state, ask the plugin developer or database administrator before removing it.

Clean only verified records

Choose an action per record. Legitimate content that was injected may be restored from a clean revision or edited through WordPress after preserving the original. A spam post confirmed to be unauthorized may be deleted or moved to an agreed status once evidence is recorded and the owner understands the effect. Fix plugin options through the plugin interface or its documentation; do not delete a wp_options row merely because its name looks unusual.

Avoid broad SQL DELETE, UPDATE, or REPLACE() commands in production. Raw text replacement can break serialized string lengths. WP-CLI wp search-replace handles serialized data for supported replacement operations and has a --dry-run option; see the official wp search-replace documentation. However, a dry run shows the impact of a string replacement; it does not prove every match should be removed or that the payload has no dependency. Limit the tables/fields you inspect, check results with the owner, and test on staging before applying a real change.

For every change, record the query or interface used, affected records, recovery backup, operator, approval, and test result. After the change, open the page as an anonymous visitor, inspect the response, check the owner dashboard, and compare the database with the snapshot. Repeat the same query and check logs/cron after an appropriate interval. If a record returns, do not delete it again; find the writing mechanism and escalate.

Address Google after the source is clean

Confirm that spam URLs are no longer generated and choose the correct server response for content that was actually removed. Do not use robots.txt to hide a path instead of cleaning it; that can prevent crawlers from observing the cleanup response. Search Console Security Issues, Manual Actions, URL Inspection, and Google search results have different purposes. Check each report that matches the symptom. The Security Issues report describes findings Google detected and the review path after they are fixed (Security Issues report).

If an URL remains visible after the source is clean, the Removals tool may provide temporary visibility handling when appropriate. It does not repair the database or stop a process from generating URLs. Preserve your initial list and repeat the inspection after cleanup; do not promise a date when Google will remove a result.

Prevent similar database changes

Limit account roles and integration access, use one credential per integration, update supported WordPress/plugins/themes, and remove unused components only after checking dependencies. Keep encrypted database backups away from the host, test restores, and review database/server write access. Log changes to posts, options, users, plugins, files, sitemaps, and redirects so you have a baseline to compare.

Do not use “gambling” as the only alarm that automatically deletes content. Use detection to alert a reviewer, then verify context and ownership. For broader security foundations, see our guide to securing WordPress for small businesses. For cases spanning files, accounts, and database, our website backup guide explains why a restorable copy should exist before emergency changes.

Frequently asked questions

Does a query that finds a gambling link prove the whole database is infected? No. It proves only that a string matched in the columns checked. Trace the record, table, owner, revision, and whether the content is legitimate.

Can I delete every row containing “casino” or “gambling”? No. Those terms may appear in legitimate editorial or business data. Search for a verified host or pattern and get the owner to approve any change.

What should I check before changing wp_options? Confirm the table and prefix, make a protected export, identify the option and owning plugin, verify that the value is not needed, and test on staging. Do not edit serialized values with raw SQL replacement.

What if the links return after cleanup? Stop repeating the deletion. Compare logs, cron, users, files, plugins, and API access to find the process that recreated the records. Ask the host or a specialist if you cannot identify the writer.

If unfamiliar gambling links are confirmed in posts or options, request WordPress incident support so the database copy, writer, and recovery plan can be reviewed before production changes.