Google Search Console may sometimes report an unexpectedly large number of URLs under:

Crawled – currently not indexed

Advertisement

A few such URLs are normal. However, when the number suddenly reaches tens or hundreds of thousands—especially when the website contains nowhere near that many genuine pages—it can indicate a technical URL-generation or URL-handling problem.

A particularly interesting example is a PHP website where Google discovers URLs such as:

https://www.exampletechsite.com/?listing/184760400/
https://www.exampletechsite.com/?listing/282844642/
https://www.exampletechsite.com/?listing/261014137/

The website owner never created these pages. Yet opening any of them displays the normal homepage.

This article explains why that happens, why Google crawls these URLs, how PHP/Apache routing can unintentionally make them appear valid, how to return the appropriate HTTP status using .htaccess, and how to clean up the resulting Search Console indexing problem.

Understanding “Crawled – Currently Not Indexed”

In Google Search Console, Crawled – currently not indexed means Googlebot has visited the URL but Google has decided not to include it in its search index at present.

This does not automatically indicate an error.

For example, Google may decide not to index a URL because it is duplicate, low-value, temporary, parameter-generated, substantially identical to another page, or otherwise unnecessary in search results.

The situation becomes concerning when a relatively small website shows something like:

Crawled – currently not indexed
Affected pages: 256,000

while the website itself may have only hundreds or thousands of legitimate pages.

That discrepancy deserves investigation.

The Fake URL Problem

Consider a PHP website whose actual homepage is:

https://www.exampletechsite.com/

Google Search Console starts reporting URLs such as:

https://www.exampletechsite.com/?listing/184760400/
https://www.exampletechsite.com/?listing/282844642/
https://www.exampletechsite.com/?listing/261014137/
https://www.exampletechsite.com/?listing/123695056/
https://www.exampletechsite.com/?listing/34718248/

The website owner confirms that:

• there is no listing section;
• these URLs were never created;
• there are no genuine pages associated with those numbers;
• opening any such URL shows the homepage.

This last point is critical.

The server may be returning:

HTTP 200 OK

for URLs that do not represent real pages.

Why Does the Homepage Appear?

Look carefully at this URL:

https://www.exampletechsite.com/?listing/184760400/

The path is actually:

/

while:

listing/184760400/

appears after the ?.

Everything after ? is part of the query string.

Therefore, the request is effectively:

Path: /
Query string: listing/184760400/

If the PHP application does not use that query string, index.php may simply render the homepage as usual.

From a visitor's perspective:

https://www.exampletechsite.com/

and:

https://www.exampletechsite.com/?listing/184760400/

may look identical.

But technically, they are different URLs.

Why This Can Create Hundreds of Thousands of URLs

Suppose Google discovers:

/?listing/10001/
/?listing/10002/
/?listing/10003/

If the server returns 200 OK for all of them, Googlebot sees each one as a potentially valid URL.

Now imagine automated systems generating:

/?listing/123456/
/?listing/876543/
/?listing/3847291/
/?listing/98765432/

There is potentially an enormous number of variations.

The website does not need to contain 250,000 physical PHP files for Google to discover 250,000 URLs.

That distinction is important:

A URL discovered by Google does not necessarily correspond to a file or database record on the server.

Where Could These URLs Come From?

Finding ?listing/... URLs in Search Console does not prove that the website generated them.

Possible sources include an old version of the website, previous PHP code, old plugins or CMS installations, historical sitemap data, database content, malformed internal links, scraper-generated URLs, spam links on external websites, automated bots, or a compromised website.

External sites can link to virtually any URL they want.

For example, a spam website could create:

https://www.exampletechsite.com/?listing/82910473/

even though that URL never existed.

The real technical problem occurs when the destination server responds:

200 OK

and displays the homepage.

That makes the nonexistent URL appear valid.

How PHP Routing Can Contribute

Consider this common .htaccess configuration:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

This configuration is common for PHP applications using front-controller routing.

It essentially says:

If the request is not for an existing file or directory, route it through index.php.

This configuration by itself is not malicious or inherently wrong.

The problem is that unwanted query-string patterns may not be rejected.

A request for:

https://www.exampletechsite.com/?listing/184760400/

still targets /, and the PHP application can render the homepage while ignoring the query string.

The result becomes:

REAL:
https://www.exampletechsite.com/
→ 200 OK
→ Homepage

FAKE:
https://www.exampletechsite.com/?listing/184760400/
→ 200 OK
→ Homepage

Google now has two URLs serving the same content.

Multiply that behavior by hundreds of thousands of variations and a major crawl-quality problem can develop.

404 vs 410 vs 301: Which Response Is Correct?

There are three responses website administrators often consider.

301 Redirect

A 301 Moved Permanently response tells search engines that the requested resource has permanently moved somewhere else.

For example:

/old-cloud-backup-page
        ↓ 301
/cloud-backup

This is appropriate when an old page genuinely has a replacement.

It is generally not appropriate to redirect hundreds of thousands of fabricated URLs to the homepage.

404 Not Found

A 404 Not Found response tells the client that the requested resource does not exist.

For an invalid URL:

/?listing/184760400/

a 404 would be technically reasonable.

410 Gone

A 410 Gone response indicates that the resource is unavailable and is intentionally being treated as gone.

For a known pattern of unwanted URLs that should never represent valid pages, 410 Gone can be an effective response.

For example:

/?listing/*
→ 410 Gone

This makes the site's intention explicit: URLs matching this unwanted pattern should not be treated as valid content.

Fixing the Problem with .htaccess

Suppose the original configuration is:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

We can add a rule specifically targeting the unwanted query-string pattern.

Example:

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteBase /

# Return HTTP 410 for unwanted ?listing/... URLs
RewriteCond %{QUERY_STRING} ^listing/ [NC]
RewriteRule ^ - [G,L]

# Existing application routing
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

The key section is:

RewriteCond %{QUERY_STRING} ^listing/ [NC]
RewriteRule ^ - [G,L]

What Does This Rule Do?

The condition:

RewriteCond %{QUERY_STRING} ^listing/ [NC]

checks whether the query string begins with:

listing/

The [NC] flag makes the comparison case-insensitive.

The rule:

RewriteRule ^ - [G,L]

uses two important flags.

G means Gone, causing Apache to return HTTP status 410.

L means Last, telling Apache to stop processing further rewrite rules for that request.

Consequently:

https://www.exampletechsite.com/?listing/184760400/

changes from:

200 OK
Homepage displayed

to:

410 Gone

while:

https://www.exampletechsite.com/

continues to return:

200 OK

Why the Rule Must Be Before Normal Routing

Order matters in .htaccess.

The unwanted URL rule should appear before the application's normal routing rules.

Conceptually:

Incoming request
      |
      v
Is query string listing/... ?
      |
   YES ──────> 410 Gone
      |
     NO
      |
      v
Normal PHP routing
      |
      v
index.php

We want to reject the unwanted request before the PHP application processes it.

Test the Fix Before Search Console Validation

Never assume an .htaccess modification is working simply because the website still opens.

Test both the invalid URL and the genuine homepage.

On Windows PowerShell:

curl.exe -I "https://www.exampletechsite.com/?listing/184760400/"

The desired result is:

HTTP/1.1 410 Gone

or an HTTP/2 equivalent such as:

HTTP/2 410

Now test the real homepage:

curl.exe -I "https://www.exampletechsite.com/"

The expected response is:

HTTP/1.1 200 OK

The final behavior should therefore be:

This is far better than returning the homepage with HTTP 200 for every fabricated URL.

Should These URLs Be Blocked in robots.txt?

Not as the initial cleanup mechanism.

For example, an administrator might consider:

Disallow: /*?listing/

This prevents compliant crawlers from crawling matching URLs.

But during cleanup, we generally want Googlebot to access previously discovered URLs and receive:

410 Gone

If Google is prevented from crawling them, it cannot directly observe that new HTTP response.

Therefore the preferred initial strategy is:

Googlebot requests bad URL
            ↓
Apache accepts request
            ↓
410 Gone
            ↓
Google processes removal

rather than immediately blocking Googlebot from accessing the URL.

Should We Add noindex Instead?

No. A noindex meta tag requires an HTML page to be returned and processed.

There is no reason to generate a normal HTML document for a URL that should not exist simply to say:

<meta name="robots" content="noindex">

For nonexistent or intentionally retired URLs, an appropriate HTTP error status such as 404 or 410 is cleaner.

Should Fake URLs Redirect to the Homepage?

Avoid this approach.

Consider:

/?listing/111/
→ Homepage

/?listing/222/
→ Homepage

/?listing/333/
→ Homepage

If each URL returns 200 OK, Google sees multiple URLs producing essentially identical content.

Even redirecting every invalid URL to the homepage is not ideal when there is no genuine relationship between those URLs and the homepage.

Redirects should generally represent an actual replacement:

/services/old-backup/
          ↓ 301
/services/cloud-backup/

not:

/random-invalid-url-827362/
          ↓
        Homepage

Why You May Also See “Soft 404”

Search Console may separately report Soft 404 URLs.

A soft 404 occurs when a page appears to be missing, empty, invalid, or otherwise error-like, but the server does not return the appropriate HTTP error status.

For example:

Request:
https://www.exampletechsite.com/nonexistent-product/

Server:
200 OK

Page:
Product not found

Google may classify this as a soft 404 because the server claims success while the content suggests failure.

Correct HTTP status codes are therefore important for both users and search engines.

What About Canonical Tags?

The genuine homepage should normally have a self-referencing canonical URL such as:

<link rel="canonical" href="https://www.exampletechsite.com/">

This helps Google identify the preferred homepage URL.

However, canonicalization should not be used as a substitute for properly handling obviously invalid URLs.

A healthy arrangement is:

Homepage
/
→ 200 OK
→ canonical: /

Real service page
/services/cloud-backup/
→ 200 OK
→ canonical: /services/cloud-backup/

Fake listing URL
/?listing/184760400/
→ 410 Gone

What to Do in Google Search Console

Once the server-side fix has been implemented, take one URL from the affected Search Console report and test it.

Confirm that the live URL now returns the intended error response.

Then open:

Search Console → Indexing → Pages → Crawled – currently not indexed

and select:

VALIDATE FIX

Validation should only be started after the server behavior has actually been corrected.

Will 256,000 URLs Disappear Immediately?

No.

Search Console reporting does not update instantly.

Google needs to recrawl and reprocess URLs, and with hundreds of thousands of affected URLs this can take considerable time.

The count may initially remain:

256K

even though the server-side problem has already been fixed.

That alone does not mean the fix failed.

The more important test is whether an affected URL now returns:

410 Gone

instead of:

200 OK

Do Not Request Indexing for the Fake URLs

The goal is not to get these URLs indexed.

Do not submit:

/?listing/184760400/

using Request Indexing.

The desired outcome is:

Google knows URL
      ↓
Googlebot requests URL
      ↓
Server returns 410
      ↓
Google recognizes URL as gone
      ↓
URL eventually disappears from relevant indexing reports

How to Investigate the Original Source

Fixing the HTTP response solves the immediate technical issue, but an administrator should also investigate why so many URLs were discovered.

Search the website files for:

listing
?listing
listing/

Also inspect the database, generated HTML, XML sitemaps, old sitemaps, application logs, access logs, previous versions of the website, JavaScript-generated links and any historical CMS installations.

Check Search Console's Security & Manual Actions → Security issues section as well.

A large quantity of unfamiliar URLs does not automatically mean the website was compromised. They could have originated from external spam links.

The investigation should determine whether:

Website itself → generates fake URLs

or:

External sources → create/link fake URLs
                         ↓
Website accepts them
                         ↓
200 OK

If it is the second case, changing the server response to 410 Gone addresses the critical behavior even though the external spam links may continue to exist.

Security Checks Worth Performing

When hundreds of thousands of unexpected URLs suddenly appear, inspect the website rather than treating the issue only as SEO.

Check PHP files for recently modified or unfamiliar scripts, unknown administrator panels, encoded PHP, suspicious eval() usage, unexpected JavaScript injection, unfamiliar .htaccess rules, unknown scheduled tasks/cron jobs, modified sitemap generators and unexpected database entries.

Also update hosting credentials, database credentials where appropriate, and ensure PHP and any frameworks/libraries are supported and patched.

Do not delete unfamiliar code blindly from a production website. Back up the site first and identify what the code does.

Recommended Final Configuration

For a PHP site where ?listing/... is definitively an invalid pattern, an Apache configuration can look like:

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteBase /

# -------------------------------------------------
# Reject fake listing query-string URLs
# Example: /?listing/123456789/
# -------------------------------------------------
RewriteCond %{QUERY_STRING} ^listing/ [NC]
RewriteRule ^ - [G,L]

# -------------------------------------------------
# Existing PHP application routing
# -------------------------------------------------
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

Always back up the existing .htaccess before changing it.

Frequently Asked Questions

1. What does “Crawled – currently not indexed” mean?

Google has already crawled the URL but currently chooses not to include it in its search index. It does not automatically mean the website has an SEO penalty.

2. Why does Search Console show 256,000 pages when my website has far fewer pages?

Google counts URLs, not physical files. Hundreds of thousands of different query-string URLs can point to the same PHP homepage.

3. Are ?listing/123456/ URLs actual files?

Usually not. In this example, listing/123456/ is part of the query string supplied to the homepage.

4. Why does every fake URL show my homepage?

The application is accepting the request and ignoring the unrecognized query string, causing index.php to render the homepage normally.

5. Is this a PHP problem?

Not necessarily a PHP bug. It is primarily a URL-handling problem. The PHP application and/or web server does not reject the unwanted query-string pattern.

6. Does this mean the website is hacked?

Not automatically. Unexpected URLs can originate from spam links, bots, old software or historical URLs. A security inspection is still advisable when the volume is unusually large.

7. Should I delete 256,000 pages from my server?

No. They may not exist as files or database pages at all.

8. Should fake URLs redirect to the homepage?

Generally no. If they never represented genuine content, returning 404 Not Found or 410 Gone is more appropriate than pretending the homepage is their replacement.

9. Is 404 or 410 better?

Both indicate that the requested content isn't available. 410 Gone is particularly useful when you deliberately want a known unwanted URL pattern treated as permanently gone.

10. What does [G,L] mean in .htaccess?

G returns HTTP 410 Gone, while L stops further rewrite-rule processing for that request.

11. Why use %{QUERY_STRING}?

Because the unwanted listing/... component appears after ?, making it a query string rather than a normal URL path.

12. Will the rule affect the homepage?

Not when correctly configured. / continues returning 200 OK; only requests whose query strings match the specified pattern are rejected.

13. How can I verify the fix?

Run:

curl.exe -I "https://www.exampletechsite.com/?listing/184760400/"

and confirm it returns 410 Gone.

Then verify:

curl.exe -I "https://www.exampletechsite.com/"

returns 200 OK.

14. Should I click “Validate Fix”?

Yes, after confirming that affected fake URLs return the intended status and genuine pages still return normally.

15. Will Search Console remove all affected URLs immediately?

No. Google must recrawl and reprocess them, so large reports can take time to change.

16. Should I use the Search Console Removals tool for all URLs?

Normally not for hundreds of thousands of pattern-based URLs. Correcting the server response is the scalable long-term solution. The Removals tool is primarily useful when temporary urgent hiding is required.

17. Should I put the fake URLs in my sitemap?

No. XML sitemaps should contain genuine canonical URLs you want search engines to crawl and potentially index.

18. Should I add noindex to fake URLs?

Usually not. Returning a proper 404 or 410 is preferable when the URL should not represent a page at all.

19. Can fake URLs consume Google's crawling resources?

Yes. A very large URL space can cause Googlebot to spend crawl activity on useless variations instead of focusing on important URLs.

20. What should I monitor after the fix?

Monitor Search Console's affected-page count, crawl statistics, server access logs, sitemap status, security reports and whether new unwanted URL patterns begin appearing.

Conclusion

A huge “Crawled – currently not indexed” count does not necessarily mean a website contains hundreds of thousands of bad pages.

Sometimes the problem is that the server accepts arbitrary URLs such as:

/?listing/123456789/

and returns:

200 OK

with the homepage.

The proper strategy is to identify the unwanted URL pattern, ensure genuine pages continue returning 200 OK, make invalid URLs return an appropriate 404 or 410 status, verify the behavior using HTTP tools, and then initiate Search Console validation.

For known unwanted ?listing/... URLs on an Apache/PHP website, a targeted .htaccess rule can turn hundreds of thousands of fake successful URLs into correctly handled 410 Gone requests—without changing genuine website pages.