You are working inside the existing production codebase for:
DATE CONTEXT: September 2026.
MISSION
Design and implement a major SEO + knowledge-base + editorial content cluster around:
- Proxy Interview / Interview Proxy
- Proxy Interview Support
- Proxy Job Support
- Technology-specific proxy interview searches
- Technology-specific proxy job support searches
- USA
- Canada
- UK
- Important technology cities within those countries
- Related technical educational queries
The objective is NOT to create hundreds of thin SEO pages.
The objective is to make ProxyTechSupport a genuinely useful technical knowledge resource that:
- answers real technical questions deeply;
- demonstrates real engineering expertise;
- attracts organic Google/Bing traffic;
- can become a source/citation for AI search and answer engines;
- supports commercial proxy interview and proxy job support pages through contextual internal linking;
- avoids keyword stuffing;
- avoids doorway pages;
- avoids duplicated city/country content;
- avoids scaled-content spam;
- avoids cannibalizing existing URLs.
IMPORTANT:
Do not start generating pages immediately.
FIRST AUDIT THE EXISTING SITE.
Inspect the complete repository and existing routes/pages.
Specifically audit:
- homepage
- /blog/
- /knowledge-base/
- /interview-questions/
- /technologies/
- proxy interview pages
- proxy job support pages
- USA pages
- Canada pages
- UK pages
- city pages
- technology pages
- AI/ML cluster
- AWS AI/ML cluster
- Azure AI cluster
- Angular cluster
- .NET cluster
- Workday cluster
- any other large technology clusters
- existing sitemap generation
- robots.txt
- canonical implementation
- JSON-LD/schema implementation
- internal linking
- breadcrumbs
- llms.txt if present
- llms-full.txt if present
DO NOT BREAK, RENAME OR REMOVE EXISTING ROUTES.
This is primarily an ADDITION + CONTENT-QUALITY + INTERNAL-LINKING project.
Before creating a new URL, search the repository to determine whether the same search intent is already covered.
If an existing page already targets the intent: ENHANCE THAT PAGE instead of creating another competing URL.
These are important search expressions collected from actual campaign/search research.
Every meaningful keyword below must be accounted for in the content architecture.
HOWEVER:
DO NOT CREATE ONE PAGE PER KEYWORD.
Map synonyms and very closely related search intent to ONE canonical high-quality page.
CORE INTERVIEW TERMS
proxy interview interview proxy proxy interview support interview proxy support interview support proxy proxy support for interview proxy for interview need proxy for interview technical proxy interview IT proxy interview
LOCATION TERMS
proxy interview USA proxy interview support USA
JOB SUPPORT
proxy job support job proxy support
TECHNOLOGY / ROLE INTERVIEW INTENTS
Java proxy interview Java proxy interview support
Python proxy interview Python proxy interview support
DevOps proxy interview DevOps proxy interview support
AWS proxy interview AWS proxy interview support
Azure proxy interview Azure proxy interview support
GCP proxy interview GCP proxy interview support
Cloud proxy interview Cloud Engineer proxy interview Cloud Architect proxy interview
Kubernetes proxy interview Terraform proxy interview
SRE proxy interview SRE proxy interview support
DevSecOps proxy interview
Cybersecurity proxy interview Cyber security proxy interview Cybersecurity proxy interview support Cloud security proxy interview Security Engineer proxy interview Security Architect proxy interview SOC Analyst proxy interview
Data Engineer proxy interview Data Engineering proxy interview Data Engineering proxy interview support
Data Scientist proxy interview Data Science proxy interview Data Science proxy interview support
Spark proxy interview Databricks proxy interview Snowflake proxy interview Analytics Engineer proxy interview
AI ML proxy interview AI ML proxy interview support AI Engineer proxy interview Machine Learning proxy interview Machine Learning Engineer proxy interview
Generative AI proxy interview Generative AI proxy interview support GenAI proxy interview GenAI proxy interview support
LLM proxy interview LLM proxy interview support
RAG proxy interview RAG proxy interview support
Agentic AI proxy interview Agentic AI proxy interview support
MLOps proxy interview MLOps proxy interview support
AI Architect proxy interview Platform Engineer proxy interview
React proxy interview Node.js proxy interview
.NET proxy interview .NET proxy interview support
Salesforce proxy interview Salesforce proxy interview support
SAP proxy interview ServiceNow proxy interview Workday proxy interview MuleSoft proxy interview
TECHNOLOGY JOB SUPPORT INTENTS
DevOps proxy job support AWS proxy job support Azure proxy job support GCP proxy job support Cloud proxy job support SRE proxy job support DevSecOps proxy job support Cybersecurity proxy job support
Data Engineer proxy job support Data Science proxy job support
AI ML proxy job support Generative AI proxy job support MLOps proxy job support
Do not miss these themes.
Create an internal planning document such as:
docs/seo/proxy-search-cluster-2026.md
The document should contain:
Keyword Search intent Existing URL if one exists Recommended canonical URL Page type Parent pillar Country applicability Technology applicability New page vs enhancement Internal links Cannibalization risk
Use a HUB → CLUSTER → SUPPORTING KNOWLEDGE architecture.
Do NOT create combinations mechanically.
Recommended conceptual hierarchy:
A. PRIMARY COMMERCIAL PILLARS
Proxy Interview Support Proxy Job Support
B. COUNTRY PILLARS
USA Canada UK
C. TECHNOLOGY PILLARS
AI/ML Generative AI Agentic AI LLM RAG MLOps
AWS Azure GCP Cloud
DevOps SRE DevSecOps Kubernetes Terraform
Java Python .NET Node.js React
Data Engineering Data Science Spark Databricks Snowflake
Cybersecurity Cloud Security SOC Security Engineering
Salesforce SAP Workday ServiceNow MuleSoft
Add others only where justified by existing demand/site architecture.
D. KNOWLEDGE ARTICLES
Architecture Implementation Production troubleshooting Debugging Performance Security Observability System design Migration Common failure modes Project walkthroughs Interview question analysis How-to-explain-project guides Technology comparisons Decision guides Incident/root-cause walkthroughs Role expectations Hiring/interview intelligence
Most NEW articles should primarily answer informational intent.
Do not make every article read like a service landing page.
A user searching:
"how does RAG reranking work"
should receive an excellent explanation of RAG reranking.
A user searching:
"why Kubernetes pod pending"
should receive a real troubleshooting guide.
A user searching:
"how to explain MLOps project in interview"
should receive a realistic architecture/project walkthrough.
A user searching:
"AWS Bedrock vs SageMaker"
should receive a useful engineering decision analysis.
Only after delivering substantial value should contextual links lead toward:
Proxy Interview Support Proxy Job Support Technology support Country support
Think:
90% useful resource 10% commercial pathway
for deeply informational content.
Every major technical guide must demonstrate information gain.
Do NOT produce generic AI prose such as:
"In today's rapidly evolving digital landscape..." "Technology is changing faster than ever..." "Whether you are a beginner or experienced professional..." "Our experts can help..."
Avoid filler.
Write like a senior engineer explaining the topic to another engineer.
Where relevant include:
- architecture flow
- components
- request lifecycle
- data flow
- implementation decisions
- failure modes
- observability
- troubleshooting methodology
- security considerations
- scaling considerations
- deployment
- testing
- performance
- cost considerations
- operational tradeoffs
- example incidents
- engineering decision tables
- commands/code/config snippets where genuinely useful
- interview follow-up questions
- common wrong approaches
- production lessons
- "what I would check first" sections
Example:
Instead of:
"Kubernetes is a popular container orchestration platform."
Provide:
"When a pod remains Pending, first separate scheduler failure from volume/network/resource provisioning. Check kubectl describe pod, scheduler events, resource requests, node selectors, affinity, taints/tolerations, PVC binding and cloud autoscaler events..."
That is the depth expected.
Before writing a technical article, verify current technology terminology/version/features from authoritative documentation whenever repository/browser capability allows it.
Prioritize:
official product documentation official release documentation standards organizations vendor engineering documentation
Do not invent September 2026 versions.
Do not automatically change an existing technology version merely to make the page look fresh.
Only update dates/version claims when the content was actually verified and changed.
For time-sensitive pages include:
Last reviewed: September 2026
ONLY after real review.
Primary countries for this project:
USA Canada UK
Country pages must contain meaningful country-specific information.
Do not simply substitute:
USA → Canada → UK
inside otherwise identical text.
Useful differentiation can include, when factually supportable:
USA:
- common enterprise hiring patterns
- technical screening structure
- contract vs permanent environment
- major technology hubs
- industries
- cloud/platform demand patterns
- commonly encountered interview formats
Canada:
- Toronto
- Vancouver
- Calgary
- Montreal
- Ottawa
- Waterloo
- relevant industries and technology ecosystems
- Canadian interview/recruiter context where supportable
UK:
- London
- Manchester
- Birmingham
- Leeds
- Edinburgh
- Glasgow
- Bristol
- Cambridge
- Reading
- relevant industries and technology ecosystems
- UK hiring/interview context where supportable
Do not invent salary statistics, employer facts or hiring statistics.
If reliable source data cannot be verified, omit the statistic.
THIS RULE IS CRITICAL.
Do NOT automatically create:
50 technologies × 40 cities × 3 services.
That produces doorway/scaled-content risk.
Create a dedicated city article only where there is enough unique information to justify it.
A useful city page should contain meaningful discussion such as:
- local technology ecosystem
- common employer/industry categories
- major role categories
- cloud/platform prevalence where supportable
- typical technical hiring patterns
- local timezone/support implications
- relevant technology communities/ecosystem
- related country guide
- related technology guide
If there is not enough unique information:
DO NOT CREATE THE CITY URL.
Let the country or technology page satisfy that query.
Develop topic candidates across these patterns.
- EXPLAINERS
What is... How ... works Architecture explained Request/data lifecycle Production architecture
- TROUBLESHOOTING
Why ... How to diagnose ... Common production failures Incident walkthrough Root cause guide
- SYSTEM DESIGN
How to design ... Architecture for ... Scaling ... Multi-region... Security architecture... Observability...
- INTERVIEW KNOWLEDGE
How to explain ... project in an interview ... system design interview guide ... architecture interview questions Senior ... interview questions Production troubleshooting interview questions Scenario-based interview questions
- PROJECT WALKTHROUGHS
Realistic enterprise project architecture Requirements Design Implementation Deployment Observability Incident handling Tradeoffs Results Follow-up questions
- COMPARISON
X vs Y When to choose X When not to choose X Cost/complexity/operational tradeoffs
- CAREER / ROLE KNOWLEDGE
What does a production ... engineer actually do? First 30/60/90 days Common project responsibilities Production responsibilities Common mistakes when joining a new project
- COUNTRY INTELLIGENCE
... interview guide USA ... engineering roles Canada ... hiring/interview landscape UK
Do not use fake anecdotes or fabricated customer stories.
Do not rigidly use exactly the same template everywhere.
But high-quality articles should usually contain:
H1
One-paragraph direct answer / context.
"Key Takeaways" when useful.
Problem/context.
Architecture or conceptual model.
Detailed explanation.
Real implementation/process.
Example or scenario.
Failure modes.
Troubleshooting/decision logic.
Tradeoffs.
Security/performance/observability where relevant.
Common mistakes.
Interview or professional implications if relevant.
Related resources.
References/sources where external technical facts were used.
Subtle CTA.
The words:
proxy interview interview proxy proxy interview support proxy job support
are commercially important and should not be artificially hidden.
Use them naturally where they match actual user intent.
However:
DO NOT keyword stuff.
Bad:
"Looking for proxy interview proxy interview support interview proxy services..."
Good:
"Proxy interview support is generally searched for by engineers who want additional technical guidance around coding, architecture or technology-specific interview rounds."
Variants can naturally appear across:
title H1 intro subheading body internal anchor text metadata
without forcing them into every paragraph.
Follow the service positioning already established by the site.
Do not claim that ProxyTechSupport impersonates a candidate or sits an interview in another person's place.
Do not create misleading promises such as:
100% job guarantee guaranteed interview guaranteed offer guaranteed salary guaranteed pass
Interview content should remain framed around expert technical guidance, mentoring, preparation and candidate-led participation.
Do not repeatedly place legal/disclaimer language throughout informational articles.
Use the existing site-wide policy/disclaimer architecture where appropriate.
Internal linking is a major part of this project.
Build semantic relationships.
Example:
RAG troubleshooting article → RAG architecture guide → Vector database comparison → LLM evaluation article → MLOps observability article → RAG interview guide → RAG proxy interview page → RAG job support page → AI/ML pillar
AWS Bedrock guide → Bedrock Knowledge Bases → Bedrock AgentCore → OpenSearch vector search → SageMaker → AWS AI system design → AWS AI interview proxy page → AWS AI job support → AWS AI/ML pillar
Country page → relevant major technologies → relevant interview guide → relevant job-support guide
Technology page → architecture content → troubleshooting content → interview knowledge → job-support service → related technologies
Avoid generic "click here" anchor text.
For every proposed page ask:
- Is there already a URL satisfying this intent?
- Is another URL targeting almost the same phrase?
- Could both pages realistically rank for the same search?
- Can they be combined instead?
If yes: prefer one stronger canonical resource.
Example:
"aws proxy interview" "aws proxy interview support"
usually DO NOT require two pages.
Use one authoritative page capable of satisfying both queries.
Likewise:
"cyber security proxy interview" "cybersecurity proxy interview"
must not become separate pages.
Implement clean JSON-LD appropriate to actual visible content.
Use only schema that truthfully represents the page.
Potential types depending on the page:
Organization WebSite WebPage Article BreadcrumbList
For genuine technical/editorial articles:
Article can be used with:
headline description datePublished dateModified author publisher mainEntityOfPage image when an actual image exists about mentions
Use BreadcrumbList when breadcrumbs are visible/appropriate.
Do not add random schema purely because schema.org supports it.
Do not mark content that is invisible to users.
Do not use fake: reviews ratings authors awards addresses FAQ answers customer statistics
IMPORTANT 2026 NOTE:
Do not depend on FAQPage markup as an SEO rich-result strategy.
Google removed the FAQ rich-result documentation/feature in 2026.
FAQ sections can still be written when genuinely useful for readers, but they are not the foundation of this strategy.
Optimize primarily for excellent human-readable HTML.
Important information must be present as textual content.
Use clear semantic HTML:
main article section nav header footer h1-h4 p ul/ol table where appropriate figure/figcaption code/pre
Do not hide important knowledge only inside JavaScript interactions.
Use descriptive headings.
Use direct answers when appropriate.
Use clean tables when a comparison is genuinely tabular.
Use lists when sequence or categorization genuinely benefits from them.
Do NOT artificially split every paragraph into "AI chunks."
Audit the existing:
/llms.txt
If it exists, improve it rather than blindly replacing it.
IMPORTANT:
llms.txt is NOT a Google Search ranking factor.
Google has explicitly clarified that it does not use llms.txt for Google Search ranking/AI visibility.
We are maintaining it because other AI agents/tools may consume it.
Use the current llms.txt v2 conventions where practical.
It should provide a clean map to authoritative site resources such as:
short factual site description
- Proxy Interview Support
- Proxy Job Support
- Get Interview Scheduled
- Profile Engineering
- major foundational guides
- RAG
- LLM
- Agentic AI
- MLOps
- AWS
- Azure
- GCP
- DevOps
- SRE
- Kubernetes
- Terraform
- Java
- Python
- .NET
- Angular
- React
- Node.js
- Data Engineering
- Data Science
- Databricks
- Snowflake
- Workday
- Salesforce
- SAP
- ServiceNow
- MuleSoft
- USA
- Canada
- UK
Link to authoritative canonical pages.
Do not dump thousands of near-duplicate URLs into llms.txt.
If the repository already supports:
/llms-full.txt
maintain it as a richer machine-readable knowledge representation.
It should prioritize:
- site identity
- services
- definitions
- technology expertise
- knowledge-base articles
- major architecture guides
- primary geography
- policies
- canonical URLs
Do not turn llms-full.txt into a keyword dump.
Do not duplicate every city page.
Prefer high-information canonical resources.
If generation is automated, make sure it stays synchronized with the actual canonical content.
Investigate whether high-value knowledge articles can cleanly expose an alternate Markdown representation without breaking the current architecture.
If appropriate, current llms.txt v2 conventions may use relationships such as a Markdown alternate and described-by relationship.
Do not add this if it creates maintenance risk or duplicate-index problems.
HTML remains canonical unless the existing architecture intentionally says otherwise.
The site already has a very large number of URLs.
Audit sitemap architecture.
If useful and compatible with the existing implementation, organize through a sitemap index such as:
sitemap-pages.xml sitemap-services.xml sitemap-technologies.xml sitemap-locations.xml sitemap-blog.xml sitemap-knowledge-base.xml
Do not duplicate URLs across sitemap files unnecessarily.
Every sitemap URL should:
- return 200
- be canonical
- be indexable
- not redirect
- not be a duplicate
Do not change an existing working sitemap architecture merely for cosmetic reasons.
If the current stack can support it cleanly, assess IndexNow integration for meaningful new/updated URLs.
Use it for:
created updated deleted
canonical URLs.
Do not fire notifications for pages that did not materially change.
Prepare the site so performance can be evaluated through:
Google Search Console Bing Webmaster Tools
Monitor:
traditional search queries organic clicks impressions CTR ranking URLs country device
Also account for 2026 generative-search reporting where available:
Google Generative AI Search performance Bing AI Performance AI citations cited URLs grounding queries
Do not measure success only by total indexed URLs.
A smaller number of authoritative pages outperforming thin pages is preferable.
Technical content should demonstrate accountability.
Where the existing site architecture allows, provide:
author/reviewer published date actual modified date technology/category references where needed
Do not fabricate engineer identities or certifications.
If no named author model currently exists, use a truthful organizational editorial attribution.
Do not automatically change every article's last-modified date.
A modification date should change only when meaningful content changes.
For changing technology articles, create a process allowing future review.
High-change subjects include:
Generative AI LLMs Agentic AI Bedrock Azure AI Vertex AI LangChain LangGraph MLOps Kubernetes cloud AI services
Before scaling, start with the strongest search-demand families.
Priority 1:
Proxy Interview Proxy Interview Support Proxy Job Support
Priority 2:
DevOps Java Python AWS Azure
Priority 3:
AI/ML GenAI Agentic AI RAG LLM MLOps
Priority 4:
Data Engineering Data Science Databricks Snowflake
Priority 5:
SRE Cybersecurity Kubernetes Terraform Cloud
Priority 6:
Salesforce Workday SAP ServiceNow MuleSoft React Node.js .NET GCP
But check existing site strength before creating anything.
Existing strong clusters should be enhanced rather than duplicated.
These are examples of the DEPTH expected.
Do not blindly create every example.
Proxy / interviews:
- What Actually Happens in a Senior Technical Interview?
- Coding Interview vs System Design vs Architecture Round
- Why Senior Engineers Fail Technical Interviews Despite Strong Experience
- How Interviewers Evaluate Production Experience
- How to Explain a Complex Project Without Giving a Generic Answer
- How to Handle Deep Follow-Up Questions in Technical Interviews
- How Technical Interview Support Works
- Technical Interview Support vs Interview Preparation
- What to Expect in a Senior Engineering Final Round
DevOps:
- Kubernetes Pod Pending: Production Troubleshooting Decision Tree
- Terraform State Locking and Drift Troubleshooting
- Argo CD Sync Failures: Root Cause Guide
- CI/CD Pipeline Failures: Application vs Infrastructure vs Runner
- Kubernetes OOMKilled Troubleshooting
- Production Rollback Design
- SRE Incident Response From Alert to Root Cause
- How to Explain a DevOps Project in an Interview
- Senior DevOps System Design Interview Guide
AI/RAG:
- Production RAG Architecture in 2026
- Why RAG Retrieval Quality Drops in Production
- Hybrid Search vs Vector Search
- Reranking Architecture
- Chunking Strategies and Their Tradeoffs
- RAG Evaluation Beyond Accuracy
- LLM Hallucination Root-Cause Analysis
- Agentic AI State and Memory Architecture
- MCP Architecture Explained
- Multi-Agent Failure Modes
- LLM Observability
- Prompt vs RAG vs Fine-Tuning
- How to Explain a RAG Project in an Interview
- Production Agentic AI System Design Interview
AWS:
- Bedrock Production Architecture
- Bedrock Knowledge Base Retrieval Troubleshooting
- Bedrock AgentCore Architecture
- SageMaker MLOps Architecture
- OpenSearch vs pgvector for AWS RAG
- IAM/KMS/VPC Architecture for Bedrock
- Bedrock Cost and Throttling Troubleshooting
- AWS AI System Design Interview Guide
Azure:
- Microsoft Foundry Production Architecture
- Azure OpenAI Production Architecture
- Azure AI Search Retrieval Architecture
- Azure AI Agent Architecture
- Azure AI Security Architecture
- Azure AI Observability
- AKS AI Workloads
- Azure AI System Design Interview Guide
Data:
- Spark Job Slow: Production Troubleshooting
- Data Skew in Spark
- Databricks Production Architecture
- Snowflake Performance Troubleshooting
- Kafka Consumer Lag Root Cause Guide
- Data Pipeline Observability
- Data Engineering System Design Interview Guide
Cybersecurity:
- IAM Incident Troubleshooting
- Cloud Security Architecture
- Zero Trust Architecture
- SIEM Alert Investigation
- DevSecOps Pipeline Architecture
- SOC Incident Walkthrough
- Security Engineer System Design Interview Guide
These articles should be capable of earning traffic independently of the commercial service.
Do not interrupt every few paragraphs with sales banners.
Preferred conversion flow:
ARTICLE VALUE ↓ RELATED TECHNICAL RESOURCES ↓ contextual sentence: "If you're dealing with this architecture in a live project..." ↓ relevant Job Support page
or:
"If you're being evaluated on this architecture in an upcoming technical interview..." ↓ relevant Proxy Interview page
Use contextual CTAs.
Not repetitive aggressive sales blocks.
Differentiate them.
KNOWLEDGE BASE:
Evergreen/reference material.
Examples: architecture definitions troubleshooting implementation how systems work production support interview concepts
BLOG:
Timely/editorial/research-oriented material.
Examples: 2026 hiring changes technology releases changing interview patterns market trends new AWS/Azure/Google platform changes new engineering practices new AI architecture developments
Do not publish the same article in both locations.
================================================== PHASE 29 — QUALITY GATE BEFORE ANY PAGE IS CREATED
A new page must answer YES to most of these:
Does it satisfy a distinct user question? Does it add information not already available on our site? Would an engineer bookmark it? Could another website reasonably cite it? Could an AI answer engine use a paragraph/table from it as a source? Does it contain real technical substance? Does it have a meaningful parent page? Does it have meaningful internal links? Is it different from existing URLs? Would we still want this page if Google did not exist?
If the answer is NO:
DO NOT CREATE THE PAGE.
IMPORTANT FOR CLAUDE CLI STABILITY:
Do not load or rewrite the entire site at once.
Work incrementally.
- Audit repository.
- Produce cluster inventory.
- Produce keyword-to-URL mapping.
- Identify duplicates/cannibalization.
- Define proposed new articles.
- Implement shared technical SEO improvements.
- Then work page-by-page.
For content implementation:
OPEN ONE FILE. READ THE ENTIRE FILE. UNDERSTAND ITS CURRENT PURPOSE. MAKE THE CHANGE. SAVE IT. VERIFY IT. MOVE TO THE NEXT FILE.
Do not attempt to keep hundreds of complete pages in context simultaneously.
Implement in the current branch/local repository.
Do NOT deploy to production unless explicitly instructed separately.
Do not delete existing content without strong justification.
Do not alter working service functionality.
At completion provide:
- Existing-site audit summary
- Keyword coverage matrix
- Existing URLs reused
- Existing URLs enhanced
- New URLs created
- URLs intentionally NOT created because of cannibalization
- New knowledge-base architecture
- New blog architecture
- Country strategy
- City strategy
- Internal-linking map
- Structured-data changes
- sitemap changes
- llms.txt changes
- llms-full.txt changes
- IndexNow changes if implemented
- files changed
- build/test results
- remaining recommended future clusters
QUALITY IS MORE IMPORTANT THAN PAGE COUNT.
The purpose of this project is to turn ProxyTechSupport into an authoritative technical knowledge resource that happens to sell expert technical support — not a website filled with SEO-generated landing pages.