FREQUENTLY ASKED QUESTIONS
Short answers about MaxAuditor Pro
This section answers the questions that most often need clarification before or after a review.
Which pages does MaxAuditor Pro review?
It checks the primary public HTML response, allowed redirects, essential DNS and TLS signals, and known public files such as robots.txt, sitemap.xml, the manifest, and security.txt. It does not sign in to administration areas.
Is this a penetration test?
No. The service does not scan arbitrary ports, attempt passwords, run exploits, or discover private networks. It reviews public web responses.
Is the score a security certificate?
No. The score helps sort findings. It is not a certification, legal opinion, search-ranking promise, or AdSense approval.
Why can the same site receive a different result later?
CDN location, cache state, deployments, regional content, third-party tags, and temporary network conditions can change a response. The scan timestamp is retained for that reason.
Which sites may I review?
Use public addresses you own or are authorized to review. The service may not be used for unauthorized access, abuse, or resource exhaustion.
Do I need to provide a password or API key?
No. Those details are not requested and should not be shared. Authenticated private pages are outside the scan scope.
How is the language preference stored?
The selected interface language is stored as a first-party preference. Complete editorial and search-indexed content is maintained in Turkish and English; interface-only locales do not create indexable editorial duplicates.
Which time zone is used for the scan time?
The base record remains ISO 8601 UTC. The interface uses the browser’s validated IANA time zone for local display.
Can the site use advertising and analytics?
AdSense and optional measurement tools can be configured. Measurement consent and Google-managed advertising privacy choices are handled separately. Ad serving also depends on AdSense account and site approval.
Can search engines and AI crawlers read the site?
Public content is allowed to known search and answer-engine crawlers through robots.txt, while API routes remain outside the index. llms.txt is a discovery aid, not a guarantee of inclusion or ranking.
If a finding says not detected, does that prove the feature is absent?
Not always. Some settings live in a provider dashboard, authenticated session, or a later request stage. The report states what it could verify from the public response and points to a second check when needed.
What should I do after changing a setting?
Scan the same production URL again, verify the expected header or redirect from the real response, and make sure the browser console has not gained a new first-party error.